Привет! Эта статья — первая в нашем буручном блоге.
Мы делаем метапоиск авиабилетов buruki.ru с человеческим лицом. Здесь мы будем делиться техническими и психологическими открытиями, которые мы совершаем каждый день в работе над проектом.
Сегодня о том, как можно быстро запустить партнерскую программу (ПП) для вашего сервиса за неделю. В качестве примера используем нашу недавно запущенную партнерскую программу по авиабилетам.
Зачем вообще нужна партнерская программа моему сервису?
Этот вопрос особенно актуален на Хабре, здесь подавляющее большинство аудитории — технари, слабо разбирающиеся в тонкостях маркетинга и душевной организации покупателей.
В крутой стартап не всегда можно с первого дня взять маркетолога, рекламщика, пиарщика и т.д. Зато запустить свою партнерскую программу и отдать вопрос привлечения аудитории профессионалам или самим пользователям — легко. Именно так поступили ребята из Dropbox — за каждого приведенного друга вы получали 500 Мб дополнительной квоты и это работало на партнерской программе, принципы которой описаны ниже.
Благодаря активной ПП, вы приобретаете дополнительный источник трафика, который не только приводит целевых посетителей, но и положительно влияет на все стороны жизни проекта:
- фидбек от тех, кто привлекает посетителей;
- фидбек от самих посетителей (некоторые категории вы, возможно, сами бы не нашли);
- положительное влияние различных источников трафика на ранжирование в поисковиках.
Что должно быть в партнерской программе?
В движке любой ПП есть четыре основных модуля:
- система учета пользователей, назначение кук и разделение источников;
- биллинг — все, что связано с деньгами (или другими бонусами пользователям);
- сбор и представление статистики;
- промо-материалы для партнеров, позволяющие эффективно продвигать ваш продукт.
Разберем каждую систему отдельно.
Учет пользователей
Задача этой подсистемы — точно разделять пользователей, понимать источники трафика, относить каждый переход к определенному партнеру и следить за тем, чтобы куки не протухали.
Учет пользователей должен работать максимально „высоко“ в системе. До того, как начнется бизнес-логика вашего приложения, вы уже должны точно знать, что это за пользователь — пришел он с поисковика или с партнерского сайта.
buruki.ru сделаны на Django, поэтому мы используем отдельную middleware, которая отвечает за обработку любого входящего запроса. Middleware проверяет, был ли уже пользователь у нас на сайте, пришел ли он по реферальной ссылке, есть ли у ссылки дополнительные параметры и т.д.
ref = request.GET.get('ref')
if not ref:
# Если ref пустой, создаём или забираем из базы
# фейкового реферера на основе хоста.
http_referer = request.META.get(
'HTTP_REFERER',
'http://direct.com'
).replace('http://www.', 'http://')
ref_host = urlparse(http_referer).hostname
referer = get_object_or_None(Referer, ref_code=ref_host)
if referer is None:
if not ref_host:
# Если ref_host пустой, то возьмём реферера
# с ref-кодом “direct.com”, который уже лежит в базе.
ref_host = 'direct.com'
else:
# Если ref_host есть, то создаём нового реферера.
# Указываем время жизни кук.
Referer.objects.create(
name=ref_host,
ref_code=ref_host,
activated=True,
cookie_lifetime=30
)
ref = ref_host
# Забираем из базы реферера по ref-коду,
# который к этому моменту или взят из GET-параметра,
# или из HTTP_REFERER, или равен “direct.com”.
try:
# Если всё прошло как надо, то получаем объект реферера.
referer = Referer.objects.get(ref_code=ref, activated=True)
except Referer.DoesNotExist:
# Если его вдруг не оказалось, то логируем это и выходим
# из middleware.
log.warning('Referrer is not found: ref_code=%s' % ref)
return
Минимальный набор информации, который необходимо хранить о каждом пользователе:
- user_id — уникальный id;
- created — время создания пользователя (+ выставление кук, минимум протухания для ПП — 15 дней, обычно 30);
- referer_url — Источник перехода (мы сохраняем полный URL первого и последнего захода на сайт);
- referer_id — партнерский аккаунт, с которого перешел пользователь (определяется по ref-параметрам ссылки). Сразу можно завести фейковые referer’ы, чтобы считать эффективность собственных источников трафика ( контекстная реклама, конкурсы, статьи на Хабре :-) );
- label — произвольная строка, которую ваши партнеры будут задавать в ссылке, чтобы самим разделять свои источники трафика и видеть в статистике эффективность разных подходов (например, так можно узнать что лучше работает — баннер в шапке блога или в сайдбаре);
- ua_string — user-agent пользователя — будет полезен в статистике;
- user_ip — eсли возможно — IP (должно быть прописано в политике конфиденциальности).
Когда вы будете реализовывать подобный middleware для вашего проекта — обязательно столкнетесь с вопросом — если один и тот же пользователь пришел от разных referer’ов — кому отнести этого пользователя? Ответ на этот вопрос зависит от специфики проекта. Мы для себя выбрали ответ — «кто последний, тот и папа». Referer, который последним довел пользователя до покупки, тот и получает вознаграждение.
visitor = get_object_or_None(Visitor, pk=visitor_id)
# Создаём нового визитора если, ...
create_visitor = (
# ... visitor_id не пустой, но в базе посетителя нет.
# Ненормальная ситуация.
visitor is None
# ... пользователя привёл новый реферер,
# и старый при этом неактивен, или новый реферер — настоящий.
# Ненастоящий реферер — это, например, Гугл или Яндекс.
or (visitor.referer != referer and (referer.real or not visitor.referer.activated))
# ... куки протухли.
or (visitor.referer_expire and visitor.referer_expire < datetime.now())
)
# Если not create_visitor, то обновляем старую запись.
Биллинг
С биллингом мы набили пару крупных шишек. Первое желание было — ничего не читать и быстро налабать. Не вышло. Мы использовали прямые операции с кошельками пользователей и, несмотря на куски двойной записи, все это обрастало костылями все больше и больше. В конце-концов, пользоваться этим стало невозможно, да и стало страшно добавлять что-то новое. Возможности аналитики и учета тоже были сильно ограничены.
В этом вопросе изобретать велосипед не стоит. Нужно использовать счета, субсчета, двойную запись, транзакции и красное сторно. В общем, все, что было изобретено бухгалтерами до нас. Мы воспользовались готовым решением из другого нашего проекта. Вам рекомендуем присмотреться к готовым решениям, например, django-oscar-accounts.
Сбор и предоставление статистики
Статистика — is a king. Статистика нужна вам, чтобы понимать как работает ваш проект, как работает партнерская программа. Статистика необходима партнерам, чтобы приводить к вам максимально эффективный трафик, экспериментировать с источниками, пробовать разные стратегии.
Статистика должна давать вам и партнерам точный ответ на главный вопрос — сколько стоит (или какой доход приносит) каждый приведенный посетитель, совершивший целевое действие.
В зависимости от специфики вашего проекта, целевые действия могут быть такими:
- регистрация (самое простое);
- продажа или отложенная продажа (когда заказ трансформируется в продажу через какой-то промежуток времени; экстремальный случай — наложенный платеж через Почту России. Почта России — всегда экстрим);
- достижение какой-то цели на сайте. (например, уровень прокачки героя в онлайн игре, приобретение премиум аккаунта, отправка анкеты).
Статистика должна предоставлять большое кол-во информации, максимально охватывая воронку конверсии.
В нашем случае мы показываем партнеру всю информацию о пользователях:
- Количество привлеченных пользователей;
- Количество поисков авиабилетов;
- Количество переходов в бронирование;
- SPV — кол-во поисков на посетителя;
- СPV — кол-во переходов в бронирование на посетителя;
- CPS — кол-во переходов в бронирование на один поиск;
- Кол-во сделанных и оплаченных бронирований (общее и в процентах);
- Наверное, самое главное — заработок на одного посетителя, на один поиск, на один переход в бронирование (EPV, EPS, EPR).
Цифр действительно много, естественно, многие из них связаны математически. Но мы убедились на своём опыте, что необходимо показывать все возможные значения. Не редко, изменения на сайте влияют на несколько параметров и статистика сразу дает полную картину.
Для дальнейшего анализа полезно давать возможность выгрузки статистики в CSV.
Еще раз — статистика, это очень, очень важно. И для вас и для партнеров.
Промо-материалы
Промо материалы — это то, чем партнеры будут завлекать пользователей к вам.
Обычно, у партнеров, которые приходят в вашу ПП, уже есть источники трафика, есть собственные ресурсы, где обитают ваши потенциальные пользователи. Дело за малым — дать партнеру промо-материалы, которые он может легко вставить к себе на площадку.
Основные виды промо, большинство из которых мы уже реализовали:
- ссылки и deeplinks (ссылки на конкретные продукты, лендинги, разделы). Самый простой инструмент, подходит для большинства задач. Если у вас длинные ссылки — не забудьте дать возможность использовать сокращалку;
- баннеры — обычные и флеш. Основные форматы — 240x400, 460x60, 200x200;
- виджеты — интерактивные блоки с вашими предложениями, результатами работы сервиса. Быстрая доставка самых ценных предложений;
- whitelabel — возможность установить всю или часть функциональности вашего сайта на внешний сайт. Мы, например, специализируемся на авиабилетах, а отельную составляющую берем от HotelsCombined — hotels.buruki.ru. Кстати, HotelsCombined, пожалуй, лучший метапоисковик отелей — сделан нашим бывшим соотечественником;
- из новенького — для привлечения трафика из соц. сетей полезно иметь генераторы подборок. То, что может заинтересовать пользователей. У нас это подборки низких цен на различные направления перелетов;
- API — для крутых перцев. Максимальный доступ к функционалу вашего сервиса.
Важно не забыть, что урлы, с которых вы отдаете виджеты или фреймы на сторонние сайты, не должны учитываться в статистике. Иначе все посетители внешнего сайта могут быть ошибочно зачтены как привлеченные пользователи.
Итого
Партнерская программа — это понятный инструмент, который подходит для 99% проектов. Делайте то, что хорошо умеете, делайте отличный продукт, а привлечением аудитории будут заниматься те, кому это ближе.
Автор: good_service