1. Видят ли потенциальные покупатели доступный продукт?
Сравнивайте полные периоды с одинаковыми условиями. Отделяйте публичные страницы продукта и материалы от административных, кабинета продавца и платёжных страниц. Сотрудники, QA и действующие продавцы не становятся новыми клиентами автоматически. Если внутренние посещения нельзя надёжно исключить, укажите ограничение.
Проверьте язык страницы, демонстрацию продукта, цену и кнопку покупки. Просмотр страницы не равен нажатию кнопки. Если нажатия не измеряются, результат неизвестен, а не нулевой. Без надёжной связи нельзя сопоставлять анонимных посетителей с заявками или заказами и рассчитывать точную конверсию из несопоставимых итогов.
2. Ведёт ли кнопка к нужному Checkout?
Пройдите по действующей публичной ссылке с компьютера и телефона, не совершая оплату. Сверьте Store, продукт, активный Price, сумму и валюту. Неустановленная ссылка, старый тариф или кнопка без реакции могут остановить покупку ещё до обработки платежа.
В API-интеграции различайте нажатие кнопки и успешное создание session. Сохраните обезличенный request/session ID и ответ сервера. Для Hosted-ссылки проверьте реальный адрес назначения и ошибку на странице. Исправляйте обнаруженную проблему, не меняя условия допуска и не создавая новые Live-цены ради прохождения теста.
3. На каком этапе оплаты останавливается покупатель?
Отдельно фиксируйте открытие Checkout, выбор способа оплаты, переход к подтверждению в банке и итоговый статус на сервере. Банк России описывает оплату через СБП по QR-коду, ссылке или кнопке с проверкой получателя и суммы. Это общая схема, а не подтверждение доступности всех способов для конкретного Store.
Ориентируйтесь на одобренные способы и модель оплаты данного Store. Успешный разовый платёж в RUB не доказывает доступность автопродления. Разделяйте ожидание, отказ, истечение срока и оплату. При неизвестном результате сначала сверьте исходный заказ; не просите сразу оплатить повторно. Возврат браузера или снимок экрана не заменяет подтверждение платежа.
4. Оплата подтверждена, но доступ не выдан?
Свяжите проверенное платёжное событие с тем же заказом и клиентом, затем с лицензией, разрешением на скачивание, квотой или сроком доступа. Проверяйте подпись и принадлежность заказа, обрабатывайте повторы идемпотентно. HTTP 200 подтверждает ответ обработчика, но не получение продукта клиентом.
При ручной выдаче также нужны ответственный и запись о выполнении, связанная с заказом. Событие purchase в аналитике — отдельный слой измерения: Яндекс описывает передачу ecommerce-данных, Google — дедупликацию по идентификатору транзакции. Наличие или отсутствие браузерного события не заменяет платёжные записи и доказательство выдачи.
5. Что считать первым настоящим клиентским заказом?
Разделяйте реальную покупку клиента, внутренний/QA/sandbox или контролируемый платёжный тест и случаи с недостаточными данными. Статуса paid, Live-session или отсутствия тестовой метки по отдельности недостаточно. Сопоставляйте заказ, платёжное событие, тестовые признаки и реальный деловой контекст клиента; неподтверждённый случай не считается доказанным коммерческим заказом.
Публикация Checkout, подтверждение продавцом начала продаж, оплата и выдача доступа — разные этапы. Последующий возврат учитывается отдельно и не стирает историю исходной оплаты. Этот список не вводит обязательный реальный платёж или дополнительное согласование перед каждым запуском.
6. Какие сведения передать поддержке?
Укажите время с часовым поясом, режим Test/Live, Store и ссылку на продукт/Price, обезличенные order/session/event/request ID, ожидаемый и фактический результат и последний подтверждённый этап. При необходимости приложите адрес страницы покупки и снимок ошибки без чувствительных данных. Сообщите, выдан ли доступ и можно ли повторить ошибку без оплаты.
Не отправляйте секретные ключи, полные платёжные реквизиты или документы личности в обычной переписке. Неизвестный результат платежа сначала обсудите с согласованным контактом поддержки. Исправьте наблюдаемый слабый этап до увеличения рекламы: если целевые посетители ещё не дошли до рабочего входа в покупку, платёжный сбой пока не доказан.