Goal: мы хотим добавить возможность отправлять postbacks для партнеров по действиям в воронке мобильного приложения.

Events:

• download
• install
• authorization Всего у нас есть 3 события для постбеков, которые мы хотели бы передавать.

download

событие из таблички "Track", то есть человек перешел на apk и начал скачивание. Нам важно в postback иметь возможность передать clickid из ссылки

Install

событие возникает при первом успешном запуске приложения. Для нас это таблица "Open". Сложность состоит в том, что нам необходимо передать параметр clickID из данных "Track". Вторая сложность состоит в том, что нам необходимо слать постбек только на ПЕРВЫЙ open приложения. Мы не должны слать его повторно.

Authorization

событие возникает при первом успешном логине внутри приложения. Для нас это таблица "Push". Она заполняется если человека зарегистрировался или залогинился внутри приложения (то есть был авторизован). Сложность опять-таки в необходимости отправлять событие только ОДИН раз.

Функциональные требования

возможность конфигурирования постбек для конкретного партнера

Нашим приложением пользуются разные партнеры, это значит что у них разные треккеры с разными форматами постбеков. Поэтому нам необходимо задавать отдельные настройки для каждого. Самый простой способ - по первой части STAG.

Примеры STAG stag=666321_693fe967c1859daf6c30bfa2, stag=partenerId_clickId

Мы предполагаем что у каждого партнера первая часть stag (partnerID) не изменена. И если мы работаем с партнером - все его ссылки будут иметь одинаковый partnerID

Таким образом мы к примеру можем завести карту соответствий: stag = xxx, тогда настройки = yyy

Оформить маппинг можем в виде google sheet таблицы

Возможность конструировать постбеки

отдельная проблема - то что у каждого партнера свой формат постбеков, поэтому нам необходимо сделать какой-то шаблонизатор для подстановки параметров в постбек урл. К примеру:

https://binom.com/postback/{stag_partnerId}/?clickID={stag_clickID}&externalClickID={params.clickID}&userID={userID}&ts={timestamp}

В примере выше:

• stag_partnerId: ид партнера из stag
• stag_clickID: ид клика из stag
• params.clickID: get параметр из начального track урл с именем clickID
• userID: ид пользователя из балицы push
• timestamp: время в формате linuxtimestapm в которое произошло событие

задержки

Оптимально нам необходимо отправлять события сразу по их возникновению, но приемлемо делать батч отправки раз в час тоже.

Производительность

было бы оптимально обойтись использованием CloudFlare workers + kv, НО важно что мы не можем хранить в KV бесконечность данных и что мы хотим минимизировать количество запросов к BQ

retry

Мы знаем что у партнеров может лежать трекер, поэтому мы должны совершать retry (идеально exponential backoff, но реально - хоть какой-то) и записывать в отдельную таблицу все отдаваемые постбеки + http status код ответа (можно и body записать первые 100 байтов)