Goal:

иметь возможность предоставить пользователям apk, который бы позволял открывать продукт в странах с гео блокировкой + блокировками зеркал.

UserFlow

Участники процесса

Tracker API

Бекенд размещенный на CloudFlare workers. Трекеров у нас может быть большое количество, на разных доменах и в разных роутах. Поэтому необходима реализация в виде отдельного worker скрипта.

Сценарии использования:

casino.com/my-internal-link?stag=xxx&utm=yyy => static-assets.com/casino.apk

track.sub-domain.com/?stag=xxx&utm=yyy => static-assets.com/casino.apk

Воркер может быть опубликован как на поддомене, так может быть и опубликован внутри вложенного роута продукта. При получении входящего запроса воркер записывает в KV или DO ip адрес и search params которые были в ссылке, после чего редиректит на апк полученное из ответа или из конфигурации.

Важно: воркер может находится в аккаунте отличном от аккаунта разворачивания Internal API, поэтому необходимо использовать HTTP API для доступа к Internal API. Это решает пробелму того, что апк может быть опубликованно внутри продукта, который находится на другом CF аккаунте, нежели основное апи мобильного приложения.

Важно: воркер должен сохранять копию всех запросов которые проходят через него в таблице редиректов в BQ (включая информацию по юзерагенту и т.п.)

Возможные проблемы: не факт, что для workera можно указать ipv4 only режим. В этом случае необходимо оставить инструкцию для активации ipv4 на домене целиком. (оптимально использовать только ipv4 адреса для детектирования пользователей)

Предполагаемые настройки worker:

tracker-api=https://some-api-url.com/path
bq-settings=standart bq env

Static

Это R2 хранилище для публикации статичных ассетов. Мы хотим внутри публиковать APK. R2 мы выбираем по причине того, что APK больше 10 мегабайт, а значит публиковать его через pages или workers нельзя. При этом R2 имеет бесплатный ergress трафик, то есть нам просто еще и дешево размещать тут большие файлы. Так же мы можем подкрепить static под разные домены.

Так же мы можем напрямую в R2 публиковать артефакты сборки в виде APK.

Internal API

Внутренне апи приложения. Это апи поддерживает несколько методов.

Mobile-Client: /product-manifest.json

Это даже не апи метод, а фактически просто статичный json. Мы запускаем его при старте мобильного приложения, для опредения необходимости запуска флоу обновления apk на клиентском устройстве). Внутри json у нас лежит что-то вроде:

{
"version": 1.0.2,
"url": "https://static.com/casino.apk"
}

Мы можем положить по одному такому манифесту на каждый продукт, к примеру cat-manifest.json, daddy-manifest.json

Mobile-Client: /api/open

АПИ метод который мы вызываем при старте приложения. Payload:

{  
  "custom_data": {  // appsflyer data, json field
    "installConversionData": {  
      "install_time": "2023-12-22 13:05:47.167",  
      "af_status": "Organic",  
      "af_message": "organic install",  
      "is_first_launch": false  
    },  
    "appOpenAttribution": {},  
    "deepLinking": "DeepLinkResult:{\"status\":\"NOT_FOUND\",\"error\":null,\"deepLink\":null}"  
  },  
  "appsflyerId": "1703250345065-1975383134428243633",  
  "appId": "com.bigfishbonansa.app",  
  "deviceId": "MTcwMzI1MDM0NTIzOC1lbl9VUy0xMDgwLjAtMjIzNi4wLTIzMTU2Mw==", //custom device id, ubiq for each instalation  
  "network_connection_type": "wifi",  
  "battery_level": "100%",  
  "device": {  // данные об устройстве
    "device_dpr": 2.75,  
    "device_width": 1080,  
    "device_height": 2236,  
    "model": "Pixel 4",  
    "os_name": "android",  
    "version": "31",  
    "manufacture": "Google",  
    "device_uuid": "unknown"  
  },  
  "fcmid": "e_fAofeISYSkAaPtWODypM:APA91bHHqT9bVz09sZ3PgIehsJBAqATdc2UOBISGX_YSm8iHyOsdqxz6nQvbv4zHqqofX1dUa3FqPNwH6oB1TZdonGpcsiBh_lMRrcND0cwiSe7R5gkntKfT-LUah5RW4su2vJ2inO1L", // firebase messaging token  
  "platform": "android", //ios
  "adsUrl": "", // если мы уже ранее имели сохраненную ссылку, то мы передаем ее тут
  "appVersion": "0.0.6+81",  
  "currentLocale": "en_US",
  "retry": 1,
  "userId": "13232"
}

Важные для нас поля:

• appID: на основании этого поля мы понимаем к какому бренду принадлежит приложение, и определяем на какое зеркало отправить пользователя
• deviceId: позволяет нам трекать уникальные установки
• adsUrl: тут мы получаем информацию, какое поле ранее было доступно у человека
• retry: это поле имеет значение отличное от 0, если урл полученный от апи не получилось открыть. То есть при запуске приложение имеет значение 0. Но если ссылку из adsUrl не получилось открыть с кодом 200, то делается повторный запрос с кодом 1, 2 и так далее. За счет этого поля мы можем настроить фолбек для пользователей в случае блокировок зеркал.
• userId: это опциональное поле, в которое мы должны передать ид пользователя, если ранее его получили через интеграцию с android webview

В ответ мы получаем json вида:

{
  action: 'redirect', 
  payload: 'https://casino.com/?stag=xxx', 
  force: true 
}

где:

• action: это целевое действие, сейчас у нас это всегда redirect
• payload: это урл который необходимо открыть. Важно: если у нас есть url params связанные с ип с которого идет запрос, то мы должны добавить их к урл из настроек.
• force: если true, то всегда будет открыт последний полученный payload. Если false - то будет использован последний сохраненный в приложении в adsUrl ранее. Сейчас мы всегда будем возвращать true.

Информация о всех запросах должна трекаться в отдельную таблицу в BQ.

Пример конфига:

{
com.catcasino.app: 
["https://catcasino.com","https://mirrorcat.com","https://superrare.fallback.com"],
casino.daddy.app: ["https://daddy.casino","https://daddy-mirror.com"],
/// ...
}

В конфиге для каждого зеркала мы указываем какой урл открывать в 0ю попытку, 1ю, 2ю и т.д.

Backend-Client: /api/track

Апи метод, в который треккер будет отстукивать пользователей, проходящих через него. payload:

{
ip: "193.233.22.2",
host: "https://originhost.com",
params: "?stag=xxx&utm=yyy",
timestamp: 2323233,
prodcut: "kent"
}

При этом response может быть просто 200, или не 200 со ссылкой на apk в body:

{
apk: "https://static.casino.com/android.apk"
}

Цель этого метода, сохранить данные для атрибуции пользователя к партнеру. Окно атрибуции - 1 день. У нас нет нужды хранить более дня информацию о кликах.

Важно: если использовать KV - окно его синхронизации между узлами CF может занимать до минуты.

KV eventually consistent

У нас уже возникали с этим проблемы на apay, и решением было отказаться от KV в сторону Durable Object. Пример реализации. DO хорош тем, что он consistant в любой момент времени, но при этом у него нет механизма expire встроенного, как в KV. Поэтому при использовании DO необходимо самим реализовать expire.

Casino

Это сайт нашего казино. Со стороны казино необходимо сделать одну доработку — для авторизированных пользователей передавать ид пользователя.

function passData(uid: string) {
typeof Android == "undefined" || Android.sendData !== "function") return;
Android.sendData(JSON.stringify({uid}))
}

Такого метода как Android.sendData нет в браузере, мы будем инджектить его из кода приложения. Если SG согласны, было бы хорошо расширить метод некоторыми дополнительными данными: Android.sendData(JSON.stringify({uid, email, tags})), в этом случаем мы не будем зависеть от интеграции customer.io и fundist, т.к. теги будут попадать к нам напрямую от браузера пользователя.

блокировка не мобильных пользователей

Для блокировки не мобиьных пользователей мы будеми использовать block правило следующего вида:

(all(http.request.headers["origin"][*] ne "https://catcasino.com"))

Для веб клиента невозможно будет указать origin не совпадающий с hostname проекта, в то время как для мобильного клиента - вполне себе возможно.

CustomerIO

Это платформа по интеграции user journey automation в продукт. Мы хотим использовать ее для отправки пушей на устройства пользователей. Для корректной сегментации нам необходимо в мобильное приложение интегрировать SDK. Customer IO Android SDK. Для корректной работы с пушами нам необходимо выполнить два условия.

Идентификация пользователя

CustomerIO.instance.identify(userId: uid, traits: {
  "email": user.email,
});

Минимально необходимый для нас параметр это userID (он же fundist id). Остальные параметры не обязательны.

Отправка FCMID

Необходимо привязывать FCMID (если он есть) к FirebaseMessagingService предоставляемому со стороны customer.io docs

Android App

Собственно говоря, сама андроид аппка. Flutter приложение, с интегрированными сдк и вебвью для открытия сайта казино.

Приложение должно поддерживать несколько специальных сценариев.

Обновление версии

Если при старте приложения в манифесте будет обнаружена версия новее текущей версии приложения - необходимо показать экрана с предложением обновиться и кнопкой скачать (которая будет вести на новое апк)

Ротация служебных доменов

В приложение должно быть встроен список служебных доменов (к примеру env переменная со списком через запятую). При старте приложения необходимо проверять наличие манифеста в формате /имяПродукта-manifest.json и ссылку для показа человеку через апи. Если при старте приложения не выходит получить ответ ни от одного из служебных доменов - необходимо показать экран о недоступности интернета. Домены предлагается перебирать последовательно.

Retry for target domain

Если урл который нами получен в payload не выходит открыть (статус код отличны от 200), то мы повторить запрос на /api/click с параметром retry=1 и так далее, в зависимости от номера попытки.

свайп движения

Мы хотим иметь два специальных движения свайпом

• свайп сверху вниз - должен запускать рефреш страницы
• свайп справа налево (назад) - должен вызывать действие back в history браузера

специальный заголовок

Для того, чтобы нас не блокировал сайт (специальные зеркала под моб устройства не должны открываться из веба), нам необходимо использовать специальный признак по которому нас будет отключать WAF на уровне зеркала. Увы при замене useragent ломается гугл авторизация, поэтому мы вынуждены идти другим образом. При добавлении специального заголовка ломается CORS на API продукта.

Поэтому, для того чтобы идентифицировать себя я предлагаю использовать заголовок origin. В нем мы будем указывать основной домен продукта, хотя открывать будем фактически зеркало. Повторить такое поведение в браузере нельзя, поэтому обычных посетителей домена будет блокировать.

список SDK

В приложение необходимо интегрировать несколько SDK:

• appsflyer sdk - сдк для аналитики
• firebase messaging sdk - необходим для отправки пушей
• customer.io sdk - необходим для интеграции с кастомером

flavors

Нам необходимо сделать пачку однотипных приложений:

• daddy
• kent
• gamma
• cat
• kometa
• arkada
• alov
• mers Фактически они отличаются только именем продукта, токенами для кастомера и фаербейса, логотипом и экраном который мы показываем при отсутствии интернета.

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

Обработка ссылок внутри приложения

У нас письма на верификацию могут приходить с разных доменов, к примеру:

• casino.com - основной домен продукта (на примере CAT: catcasino.com)
• casino-mirror.com - одно из зеркал (на примере CAT: catcasino560.com)
• app.com - специальное зеркало для приложения (на примере CAT: cf9du.app)

Общий флоу для человека выглядит так:

1. я игрок, ставлю мобильное приложение
2. внутри вебвью app.com домен с сайтом предназначенным только для мобильного приложения (его нельзя открыть в браузере)
3. я регистрируюсь внутри приложения на casino.app домене
4. мне в почту приходит письмо, вида app.com/confirm?token=xxx
5. я открываю письмо из почты, и у меня открывается мой текущий app.com домен, с внутренней ссылкой из письма (то есть app.com/confirn?token=xxx внутри вебвью)

такая схема работает, если домен с которого пришло письмо совпадает с доменом, что использовался в webview

теперь представляем кейс, что мне на этапе 4 приходит письмо с домена casino.com или casino-mirror.com, который так-же есть в списке доменов для перехвата

тогда будет выглядеть так

1. я игрок, ставлю мобильное приложение
2. внутри вебвью открывается app.com домен со специальным зеркалом
3. я регистрируюсь внутри приложения на casino.app домене
4. мне в почту приходит письмо, вида casino.com/confirm?token=xxx
5. я открываю письмо из почты, и у меня открывается мой текущий app.com домен, с внутренней ссылкой из письма (то есть app.com/confirn?token=xxx внутри вебвью)

Это означает, что я хочу зарегистрировать приложение как обработчик ссылок для доменов casino.com, casino-mirror.com, app.com. При этом я хочут обрабатывать эти ссылки как universal link, чтобы все параметры ссылки, как-то urlPath и urlSearchParams были транслированы внутрь webview, внутри приложения. Таким образом я хочу чтобы при открытии ссылки на верификацию почты, окно верификации открывалось внутри нашего приложения и всегда на текущем app.com домене (и никогда на доменах которые мы перехватываем помимо app.com). Почему важен этот сценарий — для apk мы делаем специальное зеркало, для которого внесены ряд изменений со стороны хостинга, поэтому запуск его из браузера не возможен и на нем отрабатывают скрипты атрибуции. Если же я случайно открою неподготовленное зеркало продукта внутри вебвью - его поведение будет отличаться, и я не получу информацию о пуш токенах к примеру.