타깃으로 삼을 만한 가치가 있는 키워드를 찾았다고 가정해 봅시다. 경쟁사는 그 키워드로 랭킹에 올라 있는데 내 앱은 그렇지 못한 경우일 수도 있습니다. 아니면 키워드 트래킹을 통해, 실제 수요가 있고 충분히 이길 만한 경쟁 상황을 갖춘 기회로 떠오른 키워드일 수도 있습니다.
다음 단계는 명백해 보입니다. 메타데이터를 업데이트하고 테스트하는 것입니다.
문제는 대부분의 개발자가 테스트를 잘못된 방식으로 실행한다는 점입니다. 한 번의 업데이트에서 세 가지를 바꾸고, 일주일 뒤에 확인해 결론을 내리고, 다시 세 가지를 더 바꿉니다. 이런 사이클을 네 번 반복하고 나면, 실제로 무엇이 랭킹을 움직였는지 전혀 알 수 없게 됩니다.
여기서는 읽어낼 수 있는 시그널을 만들어내는 키워드 테스트 실행 방법을 소개합니다.
왜 메타데이터를 업데이트할 때마다 시계가 초기화되는가
메타데이터 업데이트를 App Store에 제출하면, Apple은 새로운 시그널을 기준으로 앱을 다시 인덱싱합니다. 이 인덱싱 과정에는 시간이 걸립니다. 7일째에는 랭킹이 아직 전환 중입니다. 14일째가 되면 더 안정됩니다. 21일째에는 그 움직임을 재인덱싱으로 인한 일시적인 현상이 아니라, 새로운 메타데이터를 대표하는 결과로 신뢰할 수 있습니다.
이것은 느슨한 가이드라인이 아닙니다. Apple의 알고리즘이 변경을 처리하는 방식에서 비롯된 실질적인 제약입니다.
여기서 도출되는 결론은 이렇습니다. 1일째에 메타데이터 업데이트를 제출하고 10일째에 또 한 번 제출하면, 첫 번째 업데이트의 인덱싱이 끝나기 전에 두 번째 업데이트가 시계를 초기화해 버립니다. 결국 두 개의 실험이 겹쳐지고, 어느 쪽에서도 깔끔한 시그널을 얻을 수 없게 됩니다.
가장 명확한 키워드 데이터를 얻는 개발자는 21~42일마다 한 번만 업데이트를 합니다. 그보다 더 빠르게 하지 않습니다. 바로 그 제약이 데이터를 유용하게 만들어 줍니다.
세 가지 필드, 영향이 작은 순서에서 큰 순서로
모든 메타데이터 변경이 기존 랭킹에 동일한 리스크를 안기는 것은 아닙니다.
키워드 필드 (100자). 이곳은 새로운 키워드를 테스트하기에 가장 리스크가 낮은 자리입니다. 사용자에게 노출되지 않기 때문에, 여기서의 변경은 클릭률이나 전환에 영향을 주지 않습니다. 주로 검색 랭킹을 위해 인덱싱됩니다. 아직 확신이 없는 키워드를 테스트할 때는 여기서부터 시작하세요. 21일이 지나도 그 키워드로 랭킹이 움직이지 않는다면, 사용자 눈에 보이는 부분은 전혀 건드리지 않고도 무언가를 배운 셈입니다.
부제 (Subtitle, 30자). 부제는 검색 결과와 제품 페이지에 표시됩니다. 여기서의 변경은 키워드 인덱싱과, 사용자가 탭하기 전에 읽는 카피 양쪽 모두에 영향을 줍니다. 부제 변경은 키워드 필드 레벨에서 키워드를 검증한 후, 또는 그 키워드를 눈에 보이는 위치에 배치할 만큼 충분한 확신이 생겼을 때 테스트하세요.
제목 (Title, 30자). 제목은 랭킹에 미치는 가중치가 가장 크며, 검색 결과와 스토어 리스팅, 기기 홈 화면에서 사용자가 가장 먼저 보는 요소입니다. 제목 변경은 좋은 방향으로도 나쁜 방향으로도 가장 큰 랭킹 변동을 일으킵니다. 제목은 키워드 필드나 부제 레벨에서 그 키워드가 효과가 있다고 확인한 후, 그리고 21일간의 전체 재인덱싱 기간을 받아들일 준비가 되었을 때만 변경하세요.
순서는 이렇습니다. 먼저 키워드 필드, 다음 부제, 마지막으로 제목. 검증에서 확정으로 단계적으로 나아가는 것입니다.
깔끔한 테스트 실행하기
깔끔한 테스트란 한 번의 업데이트 사이클에서 하나의 변수만 바꾸는 것입니다.
실제로는 다음과 같습니다.
- 테스트하고 싶은 키워드를 정합니다.
- 현재 키워드 필드에서 가장 성과가 낮은 키워드를 제거합니다.
- 그 자리에 새로운 키워드를 추가합니다.
- 업데이트를 제출합니다. 날짜를 기록합니다.
- 21일간 기다립니다.
- 새 키워드의 순위를 기준선(baseline)과 비교해 확인합니다.
이것으로 실험은 완료됩니다. 키워드 하나를 넣고, 하나를 빼고, 하나의 21일 윈도우로 측정한다. 그것이 전부입니다.
Marteso의 버전 히스토리는 각 메타데이터 업데이트를 자동으로 기록합니다. 21일째에 해당 버전을 불러와 무엇이 바뀌었는지 정확히 확인할 수 있으며, 메모나 기억에서 맥락을 다시 짜맞출 필요 없이 전후의 키워드 랭킹을 비교할 수 있습니다.
21일째에 시그널 읽어내기
21일째에는 세 가지 결과 중 하나를 보게 됩니다.
키워드가 긍정적으로 움직였다. 랭킹에 진입했거나 순위가 개선되었습니다. 한 사이클 더 유지하고, 부제에서 보강하면 그 성과를 더 키울 수 있을지 검토해 보세요.
키워드가 움직이지 않았다. 변동 없이 유지되었거나 아예 랭킹에 진입하지 못했습니다. 이것은 실패한 테스트가 아니라 데이터입니다. 그 키워드는 충분한 가중치로 인덱싱되기 위해 제목 레벨의 배치가 필요할 수도 있고, 평점과 인게이지먼트에서 오는 더 많은 관련성 시그널이 필요할 수도 있습니다. 결과를 기록하고, 다른 후보를 그 슬롯에 교체해 넣으세요.
키워드는 움직였지만, 다른 키워드가 떨어졌다. 트레이드오프가 발생한 것입니다. 새로운 단어가 같은 의미 클러스터 안에 있는 기존 키워드와 인덱싱 가중치를 두고 경쟁하고 있을 수 있습니다. 다음 업데이트를 하기 전에, 전략적으로 어느 쪽 랭킹이 더 중요한지 판단하세요.
테스트를 읽을 수 없게 만드는 단 하나의 실수
잘 안 되는 키워드 테스트 대부분은 키워드가 틀려서가 아닙니다. 같은 윈도우 안에서 다른 무언가가 바뀌었기 때문입니다.
앱 업데이트, 평점 요청 프롬프트 추가, 스크린샷 변경 등을 키워드 업데이트와 함께 제출하면, 모두 변수를 끌어들이게 됩니다. 21일째에 관측되는 랭킹 변화가 키워드 때문인지, 스크린샷 때문인지, 평점 프롬프트 때문인지, 아니면 그것들의 조합 때문인지 알 수 없게 됩니다.
가능한 한 키워드 테스트는 다른 변경과 분리하세요. 진행 중인 키워드 테스트 도중에 버그 수정을 제출해야 한다면, 버전 히스토리에 기록해 두세요. 스크린샷과 키워드를 동시에 바꿔야 한다면, 테스트가 덜 깔끔해진다는 점을 받아들이고 결론을 내리기 전에 더 긴 윈도우를 두세요.
복리 효과
12개월 후에 가장 강력한 키워드 커버리지를 갖춘 개발자는 연 1회 ASO 감사를 하는 사람들이 아닙니다. 그들은 일관되게 단일 변수 사이클을 돌리는 사람들입니다.
여덟 번의 깔끔한 21일 테스트를 거치면, 가장 약한 키워드 슬롯 여덟 개를 그동안 찾아낸 가장 성과가 좋은 대체 후보 여덟 개로 교체한 셈이 됩니다. 그것이 바로 증거에 기반해 구축된 키워드 필드입니다. 각 사이클은 다음 사이클을 더 빠르게 만들어 줍니다. 무엇이 효과가 있었고, 무엇이 효과가 없었으며, 그 이유가 무엇이었는지에 대한 명확한 기록이 손안에 있기 때문입니다.
Marteso의 키워드 트래킹은 키워드별 7일 및 30일 순위 추세선을 전체 메타데이터 업데이트 히스토리와 나란히 보여줍니다. 매주의 습관은 단순합니다. 현재 메타데이터가 여전히 효과를 내고 있는지 확인하고, 행동할 가치가 있는 시그널이 있다면 가려내고, 다음 단일 변수 테스트를 계획하는 것입니다. 대부분의 주에는 아무것도 바뀌지 않습니다. 진짜 시그널이 나타났을 때, 그것에 깔끔하게 대응할 수 있는 구조가 갖춰져 있는 것입니다.
오늘 해야 할 단 한 가지
키워드 필드를 여세요. 현재의 100자 안에서 가장 성과가 낮은 키워드를 찾으세요. 추천 항목이나 경쟁사 분석에서 대체 후보를 하나 정하세요.
단 한 번의 업데이트를 계획하세요. 그 키워드 하나만 교체하고, 제출하고, 날짜를 기록하고, 21일 후에 다시 확인하세요.
이것이 완전한 테스트입니다. 한 번 실행해 보고 무엇을 배울 수 있는지 확인하세요. 그런 다음 다시 실행하세요.