Почему сумма расходов по строкам не совпадает с итогом отчёта

В рекламном отчёте итоговый расход — 100,00 BYN, а три видимые строки дают 99,99 BYN. Разница в одну копейку ещё не доказывает потерю данных. Она может появиться, если система складывает исходные значения с большей точностью, а интерфейс показывает каждую строку только с двумя знаками после запятой.

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

Откуда берутся две правильные суммы

Представим три строки расхода. В источнике каждая хранится как 33,334 BYN, но в интерфейсе видна как 33,33 BYN.

Если сначала сложить исходные значения, получится 100,002 BYN. После округления общего результата до копеек выйдет 100,00 BYN.

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

Учебный пример показывает расхождение из-за порядка округления. Он не описывает реальную рекламную кампанию.

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

Проверьте, где хранится точность

Число в интерфейсе и число в выгрузке могут иметь разную точность. В Google Ads API денежное поле amount_micros хранит сумму в микроединицах: один миллион микроединиц равен одной единице валюты. Например, 33 334 000 микроединиц соответствуют 33,334 единицы валюты.

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

Для каждой выгрузки зафиксируйте:

• исходное поле и его единицу: BYN, другая валюта, микроединицы;
• точность хранения и точность показа;
• правило округления;
• шаг операции: округление строки, группы или общего итога;
• период, часовой пояс, фильтры и набор включённых кампаний.

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

Сначала исключите различия выборки

Сравнивайте суммы только после проверки одинакового состава данных.

1. Период начинается и заканчивается в одни даты и часы.
2. Используется одна валюта либо сохранён единый курс и дата пересчёта.
3. В итог и строки входят одинаковые кампании, статусы и типы расходов.
4. Корректировки, возвраты, налоги и комиссии включены по одному правилу.
5. После объединения таблиц расходы не размножились.

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

Пересчитайте два маршрута

Для диагностики нужны две контрольные величины:

1. sum_displayed — сумма значений после округления каждой строки до точности экрана.
2. rounded_raw_total — сумма исходных значений, округлённая один раз в конце.

Разность между ними должна точно воспроизводить расхождение отчёта. В учебном примере:

sum_displayed = 33,33 + 33,33 + 33,33 = 99,99 BYN
rounded_raw_total = round(33,334 + 33,334 + 33,334; 2) = 100,00 BYN
gap = 100,00 − 99,99 = 0,01 BYN

Если интерфейс показывает 100,00 BYN, а ваш rounded_raw_total тоже равен 100,00 BYN, причина найдена. Сохраните оба значения и правило округления в журнале сверки.

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

Используйте десятичный тип для денег

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

В Python для такой проверки подходит Decimal. Значения создают из строк, затем явно задают шаг и режим округления:

from decimal import Decimal, ROUND_HALF_UP

cent = Decimal("0.01")
rows = [Decimal("33.334")] * 3

sum_displayed = sum(
    value.quantize(cent, rounding=ROUND_HALF_UP)
    for value in rows
)
rounded_raw_total = sum(rows).quantize(
    cent,
    rounding=ROUND_HALF_UP,
)

print(sum_displayed)      # 99.99
print(rounded_raw_total)  # 100.00
print(rounded_raw_total - sum_displayed)  # 0.01

Модуль decimal поддерживает несколько режимов округления, включая ROUND_HALF_UP и ROUND_HALF_EVEN. В BigQuery для NUMERIC и BIGNUMERIC тоже можно явно выбрать режим. Один и тот же набор значений на границе половины шага способен дать разные результаты при разных правилах, поэтому название режима сохраняют вместе с расчётом.

Если источник отдаёт микроединицы целым числом, не превращайте их в float. Для BigQuery безопасный маршрут выглядит так:

SELECT
  ROUND(
    SUM(CAST(cost_micros AS NUMERIC)) / 1000000,
    2
  ) AS cost_byn
FROM report_rows;

В этом примере cost_byn — учебное имя. Реальную валюту берут из поля валюты аккаунта или выгрузки и не подменяют предположением.

Отделите деньги от относительных метрик

CTR, конверсию, CPC, CPL и ROAS нельзя сверять суммой видимых процентов или средним из строк. Их пересчитывают из проверенных общих числителей и знаменателей.

Например, общий CPL получают так:

CPL = общий проверенный расход ÷ общее число проверенных лидов

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

Что сохранить в журнале сверки

Запись должна позволять повторить расчёт без исходного интерфейса:

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

Критерий готовности

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

Если разницу не удалось получить из исходных строк, продолжайте проверку данных. Следующий шаг — сверить уникальность ключей, пропуски, корректировки и контрольную сумму расхода до расчёта CPL.

Источники

• Источник 1
• Источник 2
• Источник 3
• Источник 4
• Источник 5
• Источник 6
• Источник 7

Материал подготовлен редакцией WiseLab с помощью AI. Источники и фактические утверждения проверены при подготовке.