← Все статьи
Руководство

Как отслеживать расходы на WhatsApp service messages до 1 октября 2026 года

Чтобы отслеживать расходы на WhatsApp service messages до 1 октября 2026 года, измеряйте доставленные сообщения категории SERVICE через Pricing Analytics API от Meta и сохраняйте объект pricing из message status webhooks. Сегментируйте результат по номеру телефона и рынку. Объем можно оценить уже сейчас, но прогноз нужно обновить после того, как Meta опубликует ставки на октябрь — это должно произойти до 1 сентября.

Главное

  • С 1 октября 2026 года Meta будет взимать плату за каждое доставленное service message; customer service conversation больше не будет единицей тарификации.
  • Pricing Analytics отмечает такие записи полями pricing_type: REGULAR и pricing_category: SERVICE.
  • В status webhooks для платных сообщений объект pricing содержит billable: true, type: regular и category: service.
  • Ставки на service messages зависят от рынка, совпадают со ставками на utility и authentication messages для этого рынка и не имеют volume tiers.
  • Доставка сообщений в 72-часовом free entry point после Click-to-WhatsApp ads и Facebook call-to-action buttons остается бесплатной, поэтому моделируйте этот сценарий отдельно.

Что изменится 1 октября 2026 года

В официальном обновлении цен Meta указано, что non-template messages можно отправлять только в течение открытого 24-часового customer service window. С 1 октября каждое non-template message, отправленное человеком или сторонним AI, который не работает на базе Meta Business Agent, будет тарифицироваться как service message.

План измерения должен разделять три границы:

ГраницаКлассификация MetaЧто отслеживать
Ответ человека или стороннего AI в открытом windowService messageЧисло доставленных сообщений по рынкам
Ответ Meta Business AgentMeta Business Agent messageОтдельную категорию и оплату по token
Сообщение в 72-часовом free entry point windowДоставка остается бесплатнойEntry point и состояние window

К одному сообщению применяется плата только за одну категорию. Не начисляйте одновременно service charge и Meta Business Agent charge за один и тот же non-template reply. Не считайте текущую октябрьскую ставку окончательной: Meta обещает опубликовать ставки, которые вступят в силу 1 октября, до 1 сентября 2026 года и может пересматривать их до одного раза в квартал.

В предыдущем сравнении цен Meta Business Agent разобран выбор архитектуры. Руководство по rate card на июль 2026 года объясняет контекст ставок по рынкам. Эта инструкция начинается после такого решения и показывает, что команде нужно измерить до запуска тарификации.

Как отслеживать расходы на WhatsApp service messages

1. Постройте базовый уровень доставленных сообщений

Выберите репрезентативный период — обычно четыре полные недели — и запросите в Pricing Analytics категорию service. Документированный ответ Meta включает следующие поля:

ПолеКак использовать в базовом уровне
start / endЗафиксировать reporting window
phone_numberРазделить каждый отправляющий номер
countryПривязать объем к правильной ставке рынка
pricing_type: REGULARИсключить другой pricing type
pricing_category: SERVICEСчитать только service messages
volumeИзмерить доставленные service messages
costСверить начисления после запуска тарификации

Храните результат по дням, номерам телефона и странам. Не объединяйте данные в «conversations»: с октября Meta измеряет каждое доставленное business message. Диалог поддержки с пятью ответами создает пять единиц измерения, а не одну conversation.

2. Сохраняйте объект pricing из status webhooks

По данным Meta, категория и стоимость также приходят в message status webhooks. Запись платного service message выглядит так:

{
  "pricing": {
    "billable": true,
    "pricing_model": "PMP",
    "type": "regular",
    "category": "service"
  }
}

Перед агрегацией сохраняйте объект pricing вместе с собственной записью о сообщении. Важно не то, считал ли agent ответ «support»-сообщением, а то, сообщил ли Meta, что доставленное сообщение относится к category: service и является billable.

3. Сверяйте webhooks с Pricing Analytics

Ежедневно сопоставляйте два показателя:

  1. Число записей о доставке из status webhooks, где pricing.category равно service.
  2. Значение volume из Pricing Analytics, где pricing_category равно SERVICE, для того же номера телефона, страны и интервала дат.

Исследуйте расхождения, а не усредняйте их. Частые причины — поздно пришедшие status events, разные time zones, reporting window без последнего дня или сообщения, отнесенные к Meta Business Agent, а не к service.

4. Постройте прогноз, не выдумывая октябрьскую ставку

Используйте формулу, в которой объем и ставка разделены:

прогнозируемая стоимость service messages
  = объем доставленных SERVICE messages по рынку
  × опубликованная ставка service для этого рынка

Для планирования до 1 сентября можно использовать заявление Meta о том, что ставки service будут соответствовать ставкам utility и authentication для каждого рынка. Считайте текущие ставки входными данными для планирования, а не обещанием. Обновите модель после публикации официальных октябрьских ставок и не применяйте volume-tier discounts для utility / authentication к service messages: Meta прямо указывает, что у service messages нет volume tiers.

Если Business Solution Provider добавляет platform fee или service fee, учитывайте эту строку отдельно. Инструкция по аудиту счета BSP объясняет, почему объединение расходов Meta и комиссий provider скрывает решение, которое нужно принять.

5. Проверьте исключения до даты запуска

До 1 октября подготовьте небольшую acceptance matrix:

  • обычный ответ человека внутри 24-часового customer service window;
  • ответ, созданный сторонним AI внутри этого window;
  • ответ Meta Business Agent;
  • ответ внутри действующего 72-часового free entry point window;
  • один и тот же сценарий для двух рынков получателя.

Для каждого случая запишите категорию из status webhook и соответствующую строку Pricing Analytics. Так finance, support и engineering заранее получат единое определение показателей до появления первого счета.

Где применяется UnifyPort

Описанное выше измерение относится к трафику, отправляемому через официальную WhatsApp Business Platform. У команды, которая использует неофициальный интерфейс UnifyPort для inbound messages обычных аккаунтов, другой control plane: категории Meta Pricing Analytics не являются source of truth для этого пути.

UnifyPort доставляет входящее сообщение WhatsApp в стандартном envelope message.received, который также используется для Telegram, LINE, TikTok, Zalo и X:

{
  "id": "evt_7c41f0b2a9",
  "type": "message.received",
  "provider": "whatsapp",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-07-14T02:15:00Z",
  "data": {
    "conversation": { "id": "84901234567", "type": "user" },
    "sender": { "id": "84901234567", "type": "user", "name": "Minh Tran" },
    "message": {
      "id": "wamid.HBgM",
      "type": "text",
      "text": "Can you check my delivery window?",
      "direction": "inbound",
      "sent_at": "2026-07-14T02:14:58Z"
    }
  }
}

Если подпись включена, перед обработкой события проверьте X-Device-Signature по точному raw body с помощью signing_secret и X-Device-Timestamp. В справочнике по доставке webhook описаны входные данные HMAC-SHA256 и правила доставки.

Это не способ убрать плату официальной платформы, продолжая отправлять сообщения через Meta. Это отдельный вариант интеграции для команд, которым нужен inbound-доступ к обычным аккаунтам или одна нормализованная очередь для нескольких messaging-каналов.

Ограничения и компромиссы

Официальная WhatsApp Business Platform лучше подходит, если вам нужны одобренные templates, официальные campaign tools, Meta-native analytics, Click-to-WhatsApp attribution или managed support от Business Solution Provider. Сохраняйте официальный план измерения, если какая-либо часть workflow продолжает использовать эту платформу.

UnifyPort не заменяет соблюдение политик WhatsApp, официальные marketing capabilities или billing records Meta. Неофициальный интерфейс также не предоставляет категории Meta Pricing Analytics. В смешанной архитектуре ведите отдельные реестры и явно маркируйте каждый outbound path.

FAQ

Будут ли WhatsApp service messages тарифицироваться по conversations после 1 октября 2026 года?

Нет. Meta указывает, что плата начисляется за каждое доставленное service message. Считайте каждый отправленный бизнесом ответ категории service, а не каждое 24-часовое customer service window.

Какая категория Pricing Analytics используется для service messages?

Используйте pricing_type: REGULAR и pricing_category: SERVICE. Сегментируйте возвращенные volume и cost по номеру телефона, стране и reporting window.

Можно ли рассчитать окончательные расходы на октябрь уже в июле 2026 года?

Можно измерить объем и построить модель, но окончательная ставка еще не зафиксирована. Meta обещает опубликовать ставки, действующие с 1 октября, до 1 сентября 2026 года.

Получают ли service messages скидки по WhatsApp volume tiers?

Нет. В обновлении Meta указано, что у service messages нет volume tiers, хотя для utility и authentication messages они сохраняются.

Останется ли бесплатным 72-часовое free entry point window?

Да, для доставки сообщений. Meta указывает, что доставка в течение действующего 72-часового free entry point window остается бесплатной, но token usage Meta Business Agent может оплачиваться отдельно.

Следующий шаг

Если вы оцениваете нормализованный inbound-путь вместе с официальной моделью тарификации, пройдите UnifyPort Quickstart и протестируйте подписанное событие message.received до изменения production routing.

Источники