The most basic, and simplistic form of deferred deep linking is with a technique called device fingerprinting. Fingerprinting itself has a bit of a negative connotation from the web era, where advertisers would attempt use bypass cookie blockades using fingerprint parameters to uniquely identify users. When it comes to mobile, things are much different and we believe the term ‘snapshot’ is a more representative term for what actually occurs

Ну типа смотрите. Эти рекламщики в своих браузерах совсем уже распоясались. Обходят всевозможные ограничения фингерпринтами. Идентифицируют пользователей так, как хотят. Вот ведь нахалы.

Другое дело - мобилка. Это "much different" (совсем другое) и мы верим, что для нас термин "снепшот" подходит гораздо больше. Не нужно нас путать с этими токсичными рекламщиками из веба. Мы тут хорошее дело делаем.

Представляю, как ребята переживают. У них по сути весь бизнес завязан на фингерпринты (простите, снепшоты). Как только Android и iOS разработают свои системы диплинков, branch.io начнут стремительно терять свой бизнес. Но лучше уж так, чем если прямо сейчас Android под соусом Privacy Sandbox начнет урезать возможности для фингерпринта в операционках.

И все же, очень классный трюк . Нужно учиться работать с терминологией.

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

• Конкретный товар в приложении ebay://item/view?id=360703170135
• Раздел с обувью https://www.wildberries.ru/catalog/obuv
• Координаты geo:55.79378663446035,49.11699501723111
• Ссылка на почту mailto:andrei@senaev.com

Любая из ссылок выше может вести в приложение, а значит являться диплинком. Некоторые из них стандартизованы (https, geo, mailto), некоторые - нет (ebay).

Одну и ту же ссылку (geo, mailto) могут уметь обрабатывать несколько приложений. В этом случае для выбора пользователю показывается disambiguation dialog: “В каком приложении открыть ссылку?”, “А вы точно уверены?”, “А всегда открывать тут или только сейчас?”.

Ссылка может быть с фоллбеком на Web (http, https). Такие ссылки называются Web Link. Преимущество у Web Link очевидно - в случае если приложение не установлено, всегда есть фоллбек на браузер.

Чтобы избежать показа disambiguation dialog, необходимо верифицировать домен и ассоциировать его с конкретным приложением. После верификации ссылка остается такой же, но теперь можно называть ее Android App Link. Примерно так же оно работает для iOS, только называется Universal Link.

Преимущество Universal Link очевидно - можно одну и ту же ссылку передать пользователю iOS, Android или Desktop. При этом откроется именно та страница приложения/сайта, которую хочет пользователь. Без лишних подтверждений и диалогов. Где именно откроется ссылка, будет зависеть от платформы и от того, установлено ли на ней приложение.

Что делать если приложение не установлено? Очевидно, на устройстве откроется браузер и у нас будет два варианта.

1. Оставить пользователя в браузере. Чаще всего мы этого не хотим, нам нужно приложение, там выше конверсионность.
2. Сразу же, либо по кнопке (А ВОТ СМОТРИ, У НАС ЕЩЕ ПРИЛОЖЕНИЕ ЕСТЬ) перенаправить пользователя в стор за приложением. А когда приложение будет установлено - все равно показать пользователю ту страницу, которую он хотел изначально.

Второе называется Deferred Deep Link. Работает это в основном на основе фингерпринта. На HTML странице JS библиотека (чаще всего AppsFlyer или branch.io) делает вызов сервера. Сервер запоминает модель устройства, IP адрес и время. После этого библиотека редиректит пользователя в стор. Когда пользователь скачивает приложение, SDK внутри приложения идентифицируют этого пользователя по фингерпринту и перенаправляет на нужную страницу.

Итого, еще раз зафиксируем базовые термины:

• Deep link - ссылка, которая ведет приложение. Она также может содержать в себе параметры, которые приложение обработает.
• Universal Link - разновидность Deep Link с протоколом https и реальным доменом. Причем домен ассоциирован с приложением (отдельно Apple и Google). Android App Link тоже будем называть Universal Link для удобства.
• Deferred Deep Link - разновидность Universal Link, которая умеет дожидаться установки приложения и передавать в него параметры.

Источники - хорошая статья и вот еще одна

Prebid был создан как открытый инструмент для клиентских рекламных аукционов. На сайте грузится библиотека пребида с заранее добавленными биддерами. Биддеры - это рекламные сети, код которых зашит в библиотеку. Они могут принимать участие в аукционе за рекламное место на сайте. Когда сайт загружается и нужно показать рекламу, каждый бидер запрашивает свой сервер и отдает в клиентский скрипт пребида свою ставку. Та ставка, которая побеждает, показывает свою рекламу на странице. Просто и элегантно, но не решает две важные для площадок задачи:

• Телеметрия. Площадка должна понимать, как реклама работает на сайте, сколько приносит денег, какие биддеры работают лучше, а какие хуже.
• Гугл. Как не крути, но гугл - это бесценный источник трафика. На самом деле текущие интеграции с пребидом необходимы площадке для того, чтобы "дофиллить" те 20% трафика, за которые гугл не готов предложить хорошую ставку, а биддеры готовы. Часто какой-нибудь биддер знает про пользователя что-то такое, чего гугл не знает. Например, что пользователь недавно пытался купить кофеварку.

Если посмотреть со стороны, то вырисовывается очевидная картина того, как это все могло бы работать. Например, гугл пишет свой адаптер для пребида и наряду с остальными биддерами принимает участие в аукционе. Дополнительно гугл пишет модуль для аналитики (такая фича тоже есть в пребиде), который позволил бы в одном месте собирать всю информацию о работе рекламы. В этой схеме счастливы все, кроме самого гугла. Он монополист и терять свою монополию совсем не хочет. Гугл знает, что многим площадкам выгодней пользоваться просто гуглом, чем совсем от гугла отказаться.

Получается, что Гуглу выгодно сказать "либо используйте только нас, либо давайте без нас"? Тут тоже нет. Во-первых, антимонопольщики и так кошмарят гугл по всем фронтам в последние годы. Во-вторых, помним про то, что гугл - не первоисточник данных о пользователе и другие рекламные сети могут знать такие "интимные подробности" из жизни пользователя, которые гуглу тоже было бы интересно узнать.

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

Немного подробнее про "возглавить":

Всем площадкам, которые хотят допустить к рекламному аукциону биддеров помимо гугла, но при этом не потерять гугл, выдается модуль, предоставляющий такую возможность. Это так называемый Pre-Auction Module, который собирает все ставки от биддеров отправляет их в гугл. Гугл в свою очередь видит все ставки других биддеров (а мы помним, что ставка прямо пропорциональна ценности пользователей) и таким образом получает данные о пользователях из других рекламных систем. В то же время гугл оставляет за собой право сделать "решающую ставку" - например, поставить на один цент выше, чем самая высокая ставка других биддеров. Таким образом с минимальным перевесом гугл побеждает в аукционе. И это в то время, как другие биддеры играют "в закрытую", не зная начальные ставки конкурентов и зачастую ставя сильно больше, чем необходимо. Тут еще нужно напомнить, что пребид - это аукцион первой цены (сколько поставил, столько и заплатил).

Немного подробнее про "сделать мучительным":

А вот тут самое сладкое. Как мы помним, GAM умеет работать с РК по стратегии CPM. Зашел в GAM, вбил настройки РК, пополнил счет, задал цену за 1000 показов и ждешь, когда магия гугла сделает свое дело. Модуль гугла для пребида как раз работает напрямую с GAM, а GAM не умеет работать со ставками. Это касается и пребида. Биддер просто не может передать гуглу свою ставку, вместо этого биддер может передать гуглу номер рекламной кампании.

Звучит поначалу так, как будто все это вместе работать просто не может, но нет. Оно работает, и так работает подавляющее большинство пребид площадок в интернете. Следите за руками. Для каждого биддера и для каждой возможной ставки (с определенным шагом) паблишер заводит в GAM рекламную кампанию.

Площадка ставит на свой сайт пребид и пару биддеров (пусть будут yandex и criteo), а также модуль гугла. Первым делом идет запрос за бидами. Yandex отвечает ставкой 0.123456 EUR, criteo ставит 0.654321 EUR. Площадка настраивает на своей стороне округление бидов. Например, до цента. Получаем ставки 0.12 EUR, и 0.65 EUR. Модуль гугла преобразует эти ставки в айдишники рекламных кампаний, например hb_pb_yandex=0.12 и hb_pb_criteo=0.65 (важно понимать, что 0.12 - это НЕ ставка, а часть идентификатора РК в GAM). В кабинете GAM уже заведены рекламные кампании для таких айдишников, к которым привязаны соответствующие ставки. Из них гугл узнает цену, чтобы либо выбрать победителя аукциона, либо предложить свою ставку.

Гугл не спешит отвечать на вопросы "почему так?" и "нельзя ли как-то по-другому?". Видимо, текущая ситуация более чем устраивает самого крупного в мире игрока на рынке рекламы.