Facebook Adsの小数値を守るBigQuery転送型の変更

BigQuery データ転送サービスのFacebook Ads コネクターで、AdInsightsActions レポートのActionValue型対応付けがINTからFLOATへ変わります。値の小数を保持できる一方、スキーマを固定した下流処理には影響します。

要点

• 対象はFacebook Ads コネクターのAdInsightsActions.ActionValue
• 変換後のBigQuery型が整数から浮動小数点数へ変わる
• スキーマ検証、型変換、BI モデル、増分読み込みの確認が必要
• 変更前後のテーブルを同じクエリで扱う場合は互換性をテストする

今回の更新で何が変わるのか

BigQueryのリリースノートは、Facebook Ads コネクターがAdInsightsActions レポートのActionValueをINTではなくFLOATとして対応付けするよう更新されることを告知しています。広告アクションの値は整数とは限らず、小数を含む金額や評価値を表す場合があります。転送元の意味に近い型へ変えることで小数部を失うリスクを減らせますが、既存ウェアハウスで列型を整数として前提にしている処理には互換性の問題が生じます。

BigQuery データ転送サービスで自動作成されるテーブルをそのまま参照している場合、次回のスキーマ更新時に型差が現れます。INT64だけを受け付ける転送先テーブルへの挿入、dbt モデルのスキーマ契約、整数型パラメーターを使うUDF、BI ツールのフィールド分類、外部書き出しのスキーマが失敗する可能性があります。逆にFLOAT64を整数へ型変換し直すと、小数を丸めたり切り捨てたりして、広告効果や金額の集計を誤るリスクがあります。

対応は一律の型変換ではなく、ActionValueがどのアクション種類で小数を持つかをサンプルで確認することから始めます。未加工層では新しい型を保持し、既存の後続処理が整数を必要とする場合は、業務規則を明示した別列で丸めする方が安全です。パーティションをまたいで古いスキーマと新しいスキーマが混在する可能性、定期クエリやマテリアライズド表示の再作成、スキーマ変更アラートも確認してください。

変更後の初回転送では、転送元の小数値、BigQueryへ保存された値、集計結果の三点を照合します。既存表を継続利用する場合は、書き込み失敗だけでなく暗黙の丸めが起きていないかも確認し、監視項目へ加える必要があります。

実務で確認するポイント

Facebook Ads 転送を使うデータエンジニアは、対象データセットでINFORMATION_SCHEMA.COLUMNSと後続処理依存関係を調べてください。変更前後の数日を並べ、行件数、NULL、合計、小数値、コストやコンバージョン指標が維持されるかを検証する必要があります。

結局、この更新をどう見るべきか

小さな型変更ですが、広告集計の数値とパイプライン契約に直接触れます。小数を正しく保持する改善として受け入れつつ、暗黙の整数前提を先に洗い出すことが重要です。