Как найти причину старой цены в письме

На сайте товар уже стоит 4 900 рублей, а в рассылке клиент видит 4 200. Команда проверяет карточку товара в CRM: там правильная цена. Значит ли это, что ошибку исправили? Не обязательно. Письмо могло сформироваться раньше и сохранить старое значение, а изображение с ценой — остаться в отдельном кеше.

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

Диагностика должна установить, какая версия цены использовалась на каждом этапе и когда содержание стало неизменяемым.

Начните с конкретного письма и товара

Нужны ID сообщения, время его формирования, товарный вариант, регион, валюта и условия цены. SKU обозначает конкретную товарную единицу; название «кроссовки» недостаточно, если размеры или варианты стоят по-разному.

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

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

Разложите путь цены на этапы

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

Отличите свежесть копии от правильности источника

RFC 9111 описывает свежесть и проверку сохранённого HTTP-ответа. Для практической диагностики полезно различать две ситуации: копия ещё считается допустимой по настройке кеша или её уже нужно сверить с источником. Корректная настройка HTTP-кеша при этом не гарантирует свежесть самого товарного фида.

Например, CRM каждую минуту скачивает файл, который магазин пересобирает раз в сутки. Учащение скачивания не обновит цену. Аналогично свежий импорт не исправит письмо, текст которого сформирован до импорта.

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

Условный разбор старой цены

Цена изменена в 10:00. Фид собран в 10:05, импорт завершился в 10:08. Но персональные письма начали формировать в 09:55 и поставили в очередь на отправку в 10:15.

В 10:15 CRM уже знает новую цену, а часть очереди содержит старый текст. Исправление фида не меняет готовые сообщения. Решение зависит от возможностей платформы: отменить и заново сформировать очередь, повторно проверить цену перед передачей или отказаться от точной цены в сообщении, где актуальность невозможно обеспечить.

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

Задайте поведение при сомнительной цене

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

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

Запасной вариант при недоступных данных выбирают заранее. Не заменяйте пустую цену нулём и не превращайте неизвестный остаток в «в наличии». Неизвестное значение должно сохранять свой смысл до решения сценария.

Проверьте согласованность предложения целиком

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

При персональной скидке нужно восстановить правило расчёта: кто имел право, какие товары участвовали, применялся ли промокод и когда истекал срок. Сохранённая версия предложения помогает службе поддержки объяснить ситуацию.

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

Сохраните версию предложения для поддержки

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

Не обязательно хранить все персональные поля, которые участвовали в выборе. Достаточно сведений, необходимых для воспроизведения предложения и предусмотренных политикой хранения. Если используются динамические блоки, зафиксируйте, какие данные определяли их содержание.

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

Как принять исправление

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

На каждом шаге сравните источник, применённую версию в CRM и конечное письмо. Зафиксируйте, какой слой требует повторного формирования, а какой обновляется автоматически. Готовый результат — карта задержек и понятное правило действий, когда цену нельзя подтвердить.

Источники

Fielding R., Nottingham M., Reschke J., ред.. HTTP Caching. IETF. RFC 9111. 2022. Разделы 4.2 Freshness и 4.3 Validation. Проверено 22.09.2026.