Это руководство предназначено для провайдера поискового арбитража System1. Ознакомьтесь с их документацией здесь.
Отслеживание поискового арбитража в целом может быть довольно сложным, учитывая наличие ключевых слов и различных необходимых параметров данных.
У System1 одна из более сложных конфигураций передачи данных. Вместо того, чтобы передавать им ID, которые они отправляют в постбэках, они ожидают, что вы передадите им предварительно вычисленные URL-строки для вызова.
Так что вместо того, чтобы передавать им что-то вроде click_id=xxx
, они ожидают, что вы передадите что-то вроде postback_to_fire=https%3A%2F%2Fmydomain.com%2Fpb%3Fhit%3Dxxx
Уже запутались? Обязательно следуйте приведенному ниже руководству и уделите особое внимание настройке передачи данных.
Создание источника предложений System1
Во-первых, создайте новый источник предложений и используйте наш шаблон System1.
Обратите внимание на раздел передачи данных:
Здесь есть несколько очень важных моментов, которые следует учитывать:
- Мы передаем compkey и rskey, используя токен
{data-xxx}
. Это означает, что значения будут поступать из вашего источника трафика через используемую вами ссылку -- поэтому важно, чтобы ваш источник трафика имел соответствующие поля отслеживания URLad_title
иkeyword
, и чтобы они всегда передавали соответствующие значения в System1 - Мы передаем URL постбэка под
click_track_url
- он будет запущен System1 позже - Мы передаем еще один URL, в данном случае ссылку на действие, под
search_track_url
- этот параметр полностью опционален и требует добавления фиктивного лендинга в нашу воронку. Это позволит вам симулировать CTR на странице поискового арбитража, но это не особенно необходимо, ведь при поисковом арбитраже у вас и так будут высокие показатели просмотров > конверсий, так что промежуточные клики не так важны. Вы сами решаете, добавлять это или нет. Если вы решите добавить, смотрите следующий раздел об отслеживании начального CTR. - Конкретная строка для вышеуказанного:
https://{tracking-domain}/action/1?vid={visitor}&rn={current-node-id}
Обратите внимание, что поскольку мы передаем предварительно вычисленные URL в System1, нечего делать во вкладке отслеживания конверсий, и нет необходимости устанавливать постбэк на стороне System1.
Настройка используемых источников трафика
Как упоминалось ранее, нам нужно передавать пользовательские данные (заголовок объявления и ключевое слово) из источника трафика, и именно эти значения передаются в System1.
Посмотрите на предыдущее изображение -- мы используем токены {data-ad_title}
и {data-keyword}
.
Поэтому я рекомендую создать новый источник трафика, предназначенный для поискового арбитража через System1, например, TikTok (System1). Вы можете использовать соответствующий шаблон, затем добавить или настроить параметры. Возьмем наш шаблон TikTok в качестве примера:
Здесь я добавил ad_title
и установил для него значение REPLACE, а также добавил поле отслеживания keyword
со значением REPLACE.
Поскольку в TikTok нет заголовков объявлений/ключевых слов, вам нужно будет вручную заменить это в вашем URL для каждого объявления, чтобы передать соответствующий параметр заголовка.
Возьмем другой пример - Taboola:
Здесь в Taboola есть передача данных для заголовков, поэтому мы можем использовать ее как есть. Однако ключевых слов снова нет, поэтому мы должны добавить новое поле keyword
и установить его значение на REPLACE.
Цель здесь - генерировать URL объявлений и изменять данные с REPLACE --> на что-то другое в этих URL. Однако вы также можете переопределить это на уровне предложения позже, как показано ниже.
Передача данных ключевых слов в предложения
Для предложений System1 вы создаете предложение, а затем используете свой домен арбитража в качестве базового URL страницы. Остальная структура URL будет обрабатываться разделом передачи данных.
Для каждого запускаемого объявления вы будете передавать значения заголовка объявления и ключевого слова. Есть два способа изменить эти значения заголовка объявления/ключевого слова.
Вариант 1: Передача в URL из источника трафика
Это конфигурация, которую вы используете выше.
При этом ваше предложение будет просто одним предложением (URL домена поискового арбитража), и вы будете создавать разные объявления --> которые могут передавать разные значения --> генерировать разные результаты страниц поискового арбитража.
В отчетности вы бы разбивали по этому полю отслеживания заголовка объявления для анализа эффективности.
Вариант 2: Передача на уровне предложения
Теперь, поскольку вся передача данных настраивается источником предложения/предложением, вы можете вместо этого выбрать жесткое кодирование на уровне предложения.
Таким образом, вы можете создать свое предложение, выбрать System1 в качестве источника предложения, затем перейти к передаче данных и добавить переопределение на уровне предложения для полей compkey или rskey, используя опцию пользовательской строки.
Таким образом, вы можете создать несколько предложений для разных ключевых слов и чередовать их в ваших воронках, как любое предложение.
Теперь значения не будут зависеть от ваших объявлений в источнике трафика и контролируются внутри FunnelFlux:
Теперь в отчетности ваши ключевые слова могут быть разделены на разные предложения.
Плюс здесь в большем контроле внутри FunnelFlux и возможности изменять их в любое время или добавлять/удалять страницы из ротации, не трогая ваши объявления.
Минус в более ручной работе по созданию предложений и настройке вашей воронки, а также потенциальном отсутствии согласованности между вашими объявлениями и страницами поискового арбитража.
Вам также нужно будет учитывать соответствие требованиям и то, нормально ли для источников с заголовками объявлений, если партнер по поисковому арбитражу передает различные ключевые слова, которые могут не соответствовать объявлению, отображаемому пользователям.
Отслеживание начального CTR
Эта часть необязательна.
Если хотите, вы можете попробовать отслеживать CTR начальной страницы поискового арбитража. Если вы не хотите этого делать, вы можете удалить параметр search_track_url из вашего источника предложений System1.
Итак, в вашей воронке вы можете иметь узел трафика --> узел предложения (предложение System1) --> фиктивный лендинг, вот так:
Смысл этого просто в создании действия, чтобы клик мог фактически произойти на странице предложения -- иначе нет способа вызвать клик.
Фиктивный лендинг может быть чем угодно, но я бы предложил создать новую страницу, например, "Фиктивная страница CTR" и установить ее URL на что-то вроде https://mylanderdomain.com/non-existent-page
Сама страница не будет загружаться в браузере, но мы не хотим потенциально спамить какой-то реальный веб-сайт, вроде google.com или test.com, множеством случайных серверных URL-запросов, если серверы System1 будут следовать цепочке редиректов.
Теперь, когда пользователь переходит от вашего объявления > URL FunnelFlux > страница предложения System1, ему обычно будут представлены различные кнопки для клика. При клике будет запущено событие действия в FunnelFlux, отслеживающее клик. Если они кликнут что-то на следующей странице, то будет отправлена конверсия.
Это даст вам некоторое представление о CTR начальной страницы, что может быть важно для понимания подходов/согласованности.
Я бы рекомендовал делать это только если вам действительно нужны эти данные, так как это дополнительные шаги/сложности, которых вы можете в противном случае избежать.