Кратко

  • Sign in with Apple выдаёт идентификаторы в пределах команды разработчика. Покупатель связывает свои новые идентификаторы с прежними учётными записями через специальные идентификаторы переноса.
  • После 60-дневного срока Apple предлагает вернуть приложение исходной команде, подготовить перенос и передать его покупателю заново. Сотрудничество продавца может оставаться ценным уже после оплаты.

В финансовой модели приложения пользователи обычно стоят стройными рядами. В системе входа всё сложнее: новый владелец должен ещё научиться узнавать каждого из тех, кого он включил в цену покупки. Sign in with Apple отводит на эту работу определённый срок. Пользователь, который решил вернуться через три месяца, под него подстраиваться не обязан.

В технической записке TN3159 Apple устанавливает 60 дней с момента завершения передачи приложения. Для пропущенного срока предусмотрен примечательный маршрут. Команда B возвращает приложение команде A. Та готовит данные и идентификаторы переноса, снова передаёт приложение B, после чего B выполняет обмен идентификаторов.

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

Репутация переезжает, номера меняются

Руководство App Store Connect описывает удобную преемственность. Приложение, соответствующее условиям передачи, может оставаться доступным для загрузки, сохранить оценки, отзывы и Bundle ID. Пользователи продолжают получать обновления. Витрина переносит смену владельца аккуратно, вместе с накопленной репутацией.

Идентификаторы Sign in with Apple ограничены командой разработчика. Так разные разработчики не получают один универсальный номер человека, позволяющий легко сопоставлять его действия у каждого из них. У этой границы есть конкретная задача защиты приватности.

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

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

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

Последний день продавца — последний день покупателя

Отсчёт начинается с завершения передачи приложения. Продавец может подготовить идентификаторы заранее или сформировать их в течение 60 дней после принятия передачи. Покупатель должен обменять их в течение тех же 60 дней после принятия. Поздняя отправка не выдаёт получателю новые два месяца.

Поэтому скорость первой стороны определяет запас времени второй. Подготовить, отправить, обменять и связать с существующими записями — разные стадии. Отметка «отправлено» закрывает задачу в одном почтовом ящике, но не доказывает готовность системы другого владельца.

Руководство для принимающей команды описывает использование данных входа для сопоставления пользователей в период переноса. Если ждать только их повторных визитов, графиком интеграции начинают управлять привычки клиентов. Кто-то открывает приложение ежедневно, кто-то вспоминает о нём раз в сезон.

Apple позволяет выполнять пакетный перенос на стороне сервера. Пользователей, которые ещё не вошли повторно, тоже можно обработать. Команда способна завершать записи по своему плану, вместо того чтобы надеяться на внезапный прилив активности. Тихая часть базы не должна исчезать из знаменателя отчёта о прогрессе.

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

Прежний владелец снова получает приглашение

По окончании периода официальный путь восстановления запускает функции переноса через возврат и повторную передачу приложения. Инициировать и принимать передачу в App Store Connect должны соответствующие Account Holder. Это действия обеих организаций. Покупатель не может выполнить всю последовательность одним внутренним распоряжением.

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

Без журналов конкретного переноса, числа несопоставленных записей и фактических часов восстановления цену этой зависимости не посчитать. Зато видно, что стоит оговорить заранее: подготовленные данные, подтверждённое завершение сопоставлений, охват неактивных пользователей и участие в восстановлении при пропуске срока.

Оценки приложения легко показать на встрече по приобретению. Полную передачу клиентских отношений приходится подтверждать иначе. Сэкономить на этой проверке — значит оставить часть оплаченной стоимости в чужом списке дел.