Если вы занимаетесь мобильными рекламными кампаниями в Facebook, то знаете об удобных возможностях использования прямых ссылок в рекламе. Но в обычных публикациях Facebook все устроено совсем иначе. Почему так трудно предоставить пользователям такие же возможности для публикаций в Facebook Messenger, какие доступны для публикаций на «стене» компании в Facebook?

Неудивительно, что разработчики Facebook стараются убрать все возможности прямых ссылок из своего приложения. Они готовы сделать исключение лишь в том случае, если вы платите им за количество установок вашего приложения. Встроенный браузер в приложении Facebook iOS нарочно устроен так, что ваше приложение не откроется по универсальной ссылке. Это «намеренная и целенаправленная» стратегия изоляции, поэтому нет четкого понимания того, как именно работают прямые ссылки в Facebook.

Ссылки приложений в Facebook

Одна из причин блокирования универсальных ссылок в Facebook состоит в том, что разработчики Facebook стремятся продвигать собственный стандарт прямых ссылок: ссылки приложений. Это решение называется точно так же, как ссылки приложений Android, но ссылки приложений Facebook — совершенно иной стандарт, близкий к тегам Open Graph. Если вы добавите теги ссылок приложений на страницы в конце ваших ссылок, то Facebook удалит их, чтобы получить информацию о том, как устроена прямая ссылка на ваше содержимое в вашем приложении. После этого Facebook откроет ваше приложение, если оно установлено.

Вот три основных ограничения ссылок приложений Facebook.

  1. Они поддерживаются только в Facebook. Добавление этих ссылок приложения на ваш сайт не даст возможности использовать прямые ссылки из любых других приложений.
  2. Отложенные прямые ссылки не поддерживаются..
  3. Целостность ссылок в iOS нарушается. Если ваше приложение не установлено, единственный доступный вариант — App Store.

Если вы решите использовать ссылки приложений, как рекомендует Facebook, преимущество очевидно: Facebook откроет приложение, если оно установлено, а вы получите путь URI, который можно использовать для прямых ссылок. Если вы проводите маркетинговые кампании, ориентированные только на повторное привлечение пользователей, то все в порядке. Идентификации щелчков у вас по-прежнему не будет (если не использовать специализированных средств, таких как Branch, для отслеживания щелчков «задним числом» после открытия приложения), но, по крайней мере, прямые ссылки будут работать.

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

С использованием ссылок приложений Facebook связана одна проблема. Если нужны прямые ссылки при установленном приложении, то во всех прочих случаях Facebook будет отправлять пользователей прямо в App Store. Это означает, что невозможно использовать средства идентификации или поставщиков прямых ссылок, а данных о переходах у вас не будет (это касается и данных идентификации), если у кого-то нет вашего приложения.

Так не должно быть. Тег al:web:should_fall backпредназначен именно для того, чтобы управлять переадресацией пользователей, у которых нет вашего приложения, в App Store или по URL-адресу вашего веб-сайта. Если для al:web:should_fallback установлено значение true, пользователи должны быть переадресованы на URL-адрес веб-сайта (вашего веб-сайта или Branch). К сожалению, этот тег в iOS не работает уже больше года, а от команд Facebook мы слышали, что исправлять его и не собираются. Теперь Facebook будет обрабатывать прямую ссылку в iOS, если для al:web:should_fallback задано значение false.

(Примечание. В Android al:web:should_fallback по-прежнему правильно работает, но и тут в любой момент может «что-нибудь» произойти. А настроить этот тег по-разному для разных платформ невозможно.)

Многие бренды не хотят, чтобы при первой попытке работы с приложением пользователи попадали на страницу App Store или Play Store. Они не хотят жертвовать данными идентификации. Поэтому для al:web:should_fallback почти всегда устанавливают значение false. Опираясь на отзывы наших партнеров, разработчики Branch используют эту методологию, чтобы правильно учитывать все возможные «точки соприкосновения».

Обходной путь для преодоления ограничений ссылок приложений

Существует обходной путь: можно предложить предварительный просмотр веб-содержимого с прямой ссылкой. Итак, нужно установить для al:web:should_fallback значение false, показать пользователям окно предварительного просмотра и дать возможность пользователям, у которых установлено соответствующее приложение, открыть его, если нужно. Пользователи, у которых нет приложения, могут на выбор либо установить его (перейдя по отложенной прямой ссылке), либо работать с содержимым на веб-странице, а не с помощью приложения. Для этого требуется, чтобы прямая ссылка в окне предварительного просмотра поддерживала универсальные ссылки iOS, посколькуe настраиваемые схемы URI не работают в веб-представлении Facebook.

Для предварительного просмотра содержимого Branch предлагает два готовых способа. Мы «интеллектуально» отслеживаем наличие или отсутствие приложения, поэтому можем столь же «интеллектуально» переключать вызов действия между «Открыть» и «Установить» в зависимости от наличия приложения.

Смарт-баннеры приложений Journey

сли у вас есть веб-сайт с таким же содержимым, как в приложении, то смарт-баннеры приложений Journey станут подходящим решением, позволяющим превратить существующее содержимое в представления предварительного просмотра с прямыми ссылками. Такое решение повышает эффективность конверсии пользователей веб-сайта в пользователей приложения в различных ситуациях, включая иFacebook.

Branch Journeys smart banners

Представления Deepview

Если у вас нет собственного сайта или на нем недоступно содержимое приложения, то можно, включить представления Deepview, это очень просто.


Ссылки приложений Facebook решают ряд проблем при попытке преодоления изоляции приложений в Facebook, но не обладают полезными возможностями учета и статистики, необходимыми для маркетологов. Чтобы повысить удобство пользователей, вам потребуется более совершенное решение с более широкими возможностями контроля.

shares