Если кратко
AI-сервис фиксирует использование продукта и передает в биллинг данные, необходимые для расчета: клиента, услугу, вид и объем потребления, период и идентификатор операции. При тарификации по токенам учитываются входные и выходные токены, их общее количество и тип используемой операции.
Информация передается в биллинг либо по отдельным событиям, либо накопленным объемом за период. Система связывает их с клиентом и услугой, применяет тарифные правила и рассчитывает начисление, в том числе лимиты и перерасход.
Перед запуском проверяют корректность идентификаторов, единиц измерения, объема, расчетного периода и итогового начисления.
Информация передается в биллинг либо по отдельным событиям, либо накопленным объемом за период. Система связывает их с клиентом и услугой, применяет тарифные правила и рассчитывает начисление, в том числе лимиты и перерасход.
Перед запуском проверяют корректность идентификаторов, единиц измерения, объема, расчетного периода и итогового начисления.
AI-сервис фиксирует, сколько клиент использовал продукта: токены, запросы к API, генерации или обработанные документы. Чтобы на основании этих данных рассчитать оплату, информацию об использовании нужно передать в биллинг и связать с конкретным клиентом и услугой.
AI-сервис может использовать разные модели монетизации: подписку, оплату по факту использования или тарификацию по токенам. Подробнее о выборе модели можно прочитать в статье «Как монетизировать AI-сервис: подписка, оплата по использованию или токены».
В статье разберем, какую информацию AI-сервис должен передавать в систему расчетов, как их передавать и что нужно проверить, чтобы на их основе корректно рассчитывались начисления.
AI-сервис может использовать разные модели монетизации: подписку, оплату по факту использования или тарификацию по токенам. Подробнее о выборе модели можно прочитать в статье «Как монетизировать AI-сервис: подписка, оплата по использованию или токены».
В статье разберем, какую информацию AI-сервис должен передавать в систему расчетов, как их передавать и что нужно проверить, чтобы на их основе корректно рассчитывались начисления.
Какие данные передавать из AI-сервиса в биллинг
Для расчета системе не нужны все технические логи работы сервиса. Достаточно передать данные, по которым можно определить, кто использовал услугу, что именно использовал и в каком объеме.
Для расчета нужна следующая информация:
Для расчета нужна следующая информация:
- идентификатор клиента или аккаунта;
- идентификатор услуги;
- вид потребления;
- объем потребления;
- дата и время события или расчетный период;
- идентификатор операции.
Например, запись о потреблении может содержать: клиента, услугу, 25 000 токенов, расчетный период и идентификатор операции.
В биллинг передается информация, необходимая для расчета. Внутренние логи, промежуточные шаги обработки запроса, технические параметры модели и другие данные, которые не участвуют в тарификации, для этого не нужны.
Как связать потребление с клиентом и услугой
В AI-сервисе и биллинге одни и те же объекты могут называться по-разному. Поэтому при передаче данных важно заранее определить соответствие между ними.
Связь между объектами выглядит так:
Тип использования может быть разным: генерация текста, обработка изображения, обращение к определенному API или другая операция. Если для них действуют разные тарифы, системы расчетов должна понимать, к какой именно услуге относится переданное потребление.
Одного объема недостаточно. Если передать только значение «25 000 токенов», система не поймет, кому его начислить и какое тарифное правило применить. Поэтому идентификаторы клиента и услуги должны передаваться вместе с объемом использования.
Связь между объектами выглядит так:
- пользователь, аккаунт или организация в AI-сервисе → клиент в биллинге;
- тип использования в AI-сервисе → услуга в биллинге.
Тип использования может быть разным: генерация текста, обработка изображения, обращение к определенному API или другая операция. Если для них действуют разные тарифы, системы расчетов должна понимать, к какой именно услуге относится переданное потребление.
Одного объема недостаточно. Если передать только значение «25 000 токенов», система не поймет, кому его начислить и какое тарифное правило применить. Поэтому идентификаторы клиента и услуги должны передаваться вместе с объемом использования.
Какие данные передавать при тарификации по токенам
Для AI-сервисов, где стоимость зависит от количества токенов, нужны:
Входные и выходные токены должны передаваться отдельно, если для них установлены разные ставки. Модель также нужно указывать, если сервис использует несколько моделей с разной стоимостью.
Например, AI-сервис может передать информацию о клиенте, услуге, количестве входных и выходных токенов и использованной модели. Биллинг использует эти значения в соответствии с настроенным тарифом.
Для других видов потребления действует тот же принцип. Можно передавать количество API-запросов, генераций изображений, обработанных документов или другой измеримый показатель.
- количество входных токенов;
- количество выходных токенов;
- общее количество токенов;
- модель или тип операции, если они влияют на стоимость.
Входные и выходные токены должны передаваться отдельно, если для них установлены разные ставки. Модель также нужно указывать, если сервис использует несколько моделей с разной стоимостью.
Например, AI-сервис может передать информацию о клиенте, услуге, количестве входных и выходных токенов и использованной модели. Биллинг использует эти значения в соответствии с настроенным тарифом.
Для других видов потребления действует тот же принцип. Можно передавать количество API-запросов, генераций изображений, обработанных документов или другой измеримый показатель.
Как передавать данные о потреблении
Есть два основных варианта: передавать каждое событие отдельно или отправлять накопленный объем за определенный период.
При передаче по событиям сервис отправляет информацию после каждого использования: запроса, генерации, обработки документа. Такой вариант нужен, когда информацию о потреблении необходимо учитывать практически сразу. Например, клиент должен видеть остаток лимита в реальном времени или доступ к сервису нужно прекратить после его исчерпания.
При агрегированной передаче сервис сначала суммирует потребление за определенный интервал, например за час или сутки, и отправляет в биллинг одну запись за этот период. Такой вариант подходит, если нет необходимости реагировать на каждое отдельное событие и достаточно учитывать использование с определенной периодичностью. Передавать каждую операцию отдельно в этом случае не требуется.
Выбор между двумя способами зависит от того, насколько актуальными должны быть данные. Чем быстрее нужно обновлять лимиты и принимать решения по доступу к услуге, тем важнее передача отдельных событий.
При агрегированной передаче сервис сначала суммирует потребление за определенный интервал, например за час или сутки, и отправляет в биллинг одну запись за этот период. Такой вариант подходит, если нет необходимости реагировать на каждое отдельное событие и достаточно учитывать использование с определенной периодичностью. Передавать каждую операцию отдельно в этом случае не требуется.
Выбор между двумя способами зависит от того, насколько актуальными должны быть данные. Чем быстрее нужно обновлять лимиты и принимать решения по доступу к услуге, тем важнее передача отдельных событий.
Как данные о потреблении используются для расчета
После передачи данных биллинг связывает потребление с клиентом и услугой, применяет тарифные правила и формирует начисление.
Предположим, сервис передал информацию о 25 000 использованных токенов. По тарифу 20 000 токенов уже включены в подписку, а еще 5 000 оплачиваются отдельно как перерасход.
Система расчетов применяет эти правила к переданному объему и рассчитывает начисление за превышение лимита.
Такая схема используется не только при тарификации по токенам. В моделях с оплатой за фактическое использование биллинг учитывает включенный объем и начисляет плату за превышение по установленной ставке. Подробнее об этом: «Оплата за использование: что это и как работает в SaaS».
Предположим, сервис передал информацию о 25 000 использованных токенов. По тарифу 20 000 токенов уже включены в подписку, а еще 5 000 оплачиваются отдельно как перерасход.
Система расчетов применяет эти правила к переданному объему и рассчитывает начисление за превышение лимита.
Такая схема используется не только при тарификации по токенам. В моделях с оплатой за фактическое использование биллинг учитывает включенный объем и начисляет плату за превышение по установленной ставке. Подробнее об этом: «Оплата за использование: что это и как работает в SaaS».
Что проверить перед запуском передачи данных
До запуска стоит проверить:
Перед запуском стоит взять несколько реальных сценариев и вручную проверить результат расчета. Это позволяет обнаружить ошибки в идентификаторах, единицах измерения или тарифных правилах до того, как они попадут в реальные начисления.
- клиент определяется однозначно, без дублей и пересечений идентификаторов;
- потребление привязано к нужной услуге;
- единица измерения совпадает с той, которая используется в тарифе;
- объем передается корректно, без потерь и двойного учета;
- расчетный период одинаково определяется в AI-сервисе и системе расчетов;
- в биллинге настроены необходимые правила: включенный объем, лимиты, ставка за перерасход;
- тестовые данные дают ожидаемое начисление.
Перед запуском стоит взять несколько реальных сценариев и вручную проверить результат расчета. Это позволяет обнаружить ошибки в идентификаторах, единицах измерения или тарифных правилах до того, как они попадут в реальные начисления.
Итог
Схема передачи информации выглядит так: AI-сервис фиксирует потребление → формирует запись с необходимыми данными → связывает ее с клиентом и услугой → передает в биллинг → система применяет тарифные правила и формирует начисление.
Токены являются одним из основных показателей использования для AI-сервисов, но тот же подход работает с API-запросами, генерациями, документами и другими единицами.
Если сервис работает по модели оплаты за использование, важно заранее определить, какие данные должны поступать в биллинг и как они связаны с клиентом, услугой, тарифом и расчетным периодом. Это позволяет избежать ошибок в начислениях и лишних доработок после запуска.
LBX Биллинг помогает автоматизировать такие сценарии для SaaS и digital-продуктов.
Если сервис работает по модели оплаты за использование, важно заранее определить, какие данные должны поступать в биллинг и как они связаны с клиентом, услугой, тарифом и расчетным периодом. Это позволяет избежать ошибок в начислениях и лишних доработок после запуска.
LBX Биллинг помогает автоматизировать такие сценарии для SaaS и digital-продуктов.
