[기획자의 개발지식] URL 랜딩을 바꾸는 방식
내가 실무를 하면서 개발자와 일하며 알게 된 지식들을 기획자 side에서 이해한 내용과 검토한 내용에 대해서 정리해보면 좋을 것 같다고 생각이 들었다.
이 주제의 첫번째 내용은 페이지의 URL과 관련한 개발지식이다.
① Redirect (리다이렉트)
A라는 URL로 사용자가 진입하였으나 A라는 URL이 사라졌을 수 있다. 진입한 유저가 이탈되지 않도록 하기 위해서는 A를 대체할만한 B라는 URL 페이지가 있다면 B로 갈 수 있도록 처리해주고, 대체할 페이지가 없다면 적어도 서비스의 '홈' 화면으로라도 보내주는 것이 유저의 이탈을 막을 수 있다. 이렇게 A라는 페이지가 없을 때, 다른 페이지로 보내주는 방식을 '리다이렉트(redirect)'라고 한다.
내가 담당하는 서비스의 URL이 변경된다면, 변경되는 URL로 리다이렉트 처리되도록 하는 작업도 함께 챙길 필요가 있다.
리다이렉트 처리 방식 구조도② URL 분기처리
이번에 프로젝트를 진행하면서 '이런 식으로도 처리가 가능하구나' 배운 부분이 있다. 바로 같은 URL을 사용하지만, 사용자가 보는 UI는 2개로 분기하여 다른 화면으로 나오도록 하는 부분이었다. A라는 URL로 접속을 하게 되면 특정 조건에 해당되는지 판별을 하고, 조건에 해당하지 않는다면 a화면으로 노출하고 조건에 해당한다면 b라는 화면으로 노출하는 방식이다.
추후에 계획하고 있는 프로덕트 방향성이 '2개인 UI를 1가지로 통합'하려는 부분이 있다보니, 다른 UI지만 먼저 동일한 URL을 사용하도록 처리한 부분이 있었다. 이렇게 처리해두고 나서 보니 기획자 입장에서 유의해야할 지점들이 있었다.
1. 각각 다른 UI 서비스라는 것을 데이터를 볼 때 구분할 수 있을까?
처음 URL을 통합하는 논의를 할 때 가장 먼저 떠올랐던 질문이었는데, 결론부터 말하자면 내가 보는 데이터 툴에서는 구별은 할 수 있었다. 회사에서 보는 데이터 툴은 GA와 Amplitude이었는데 두개의 툴에서는 모두 구별이 가능했다.
우선 GA4에서는 UI가 다를 때 각각 다른 page_id를 사용할 수 있었다. (특정 조건에 해당한다는 정보를 활용해서 page_id를 분기)
반면, Amplitude 같은 경우에는 URL를 기반으로 screen_id 를 사용하고 있었고, 동일한 UI라면 동일한 screen_id를 사용할 수 밖에 없는 구조였다. 다만, 속성 정보(property)로 다른 UI임을 구분할 수 있는 정보값을 넣을 수 있었다. 페이지에서 발생하는 모든 이벤트에 속성 정보를 심어줘야 하는 부분이 있긴 했지만 결론적으로는 구별은 할 수 있었다.
2. 운영/관리가 복잡해질 수 있다.
2개의 UI를 운영하고 있는 시점에서 A 지면에서는 있는 URL이 B지면에선 없는 경우가 있다. 이런 케이스를 고려하여 세세하게 랜딩처리를 해줘야 하는 부분들이 생기게 된다. (개발자분들이 꼼꼼하게 리다이렉트 처리해줘야 하는 작업들이 많아진다는 얘기..)
커머스이다보니 상품의 정렬순, 필터를 물고 랜딩URL로 운영해서 쓰는 케이스가 있는데, 자주 쓰는 정렬순과 필터에 대해서는 A 지면과 B 지면이 호환될 수 있도록 미리 영향도를 파악해서 사전 작업을 진행해야 했다.
개발 지식이 빠삭한 것은 아니라 원리를 설명하는데는 부족한 부분이 있을테지만, 이런 작업을 진행하는데 기획자로서 고려해야할 요소는 무엇이 있을지 그 view를 공유해보고 싶었다!
나와 비슷한 고민이 있을 어떤 기획자를 위해..
