BigQuery レガシーSQLを使用しているジョブを洗い出す

BigQuery レガシーSQLを使用しているジョブを洗い出す

・2025年8月1日から、GoogleSQLがBigQueryのデフォルト言語になる
・レガシーSQLを引き続き使う場合、明示的に指定する必要がある
・まずは、レガシーSQLを使用しているジョブを洗い出し、対応要否の確認を

2025年8月1日から、GoogleSQLがBigQueryのデフォルト言語になることがGoogleより発表されました。

今後も、レガシーSQLを使う場合、オプション等で明示的に指定する必要があります。

レガシーSQLを使用しているケースはあまりないと思いますが、BigQueryで簡単に確認できます。

Google Cloud リファレンスより

[PROJECT_ID.]`region-REGION`.INFORMATION_SCHEMA.JOBS[_BY_PROJECT]

この構文を使います。

レガシーSQLを使っているジョブを洗い出す

BigQueryをひらき、クエリに上記SQLをコピー&ペーストします。

プロジェクトIDと、リージョンをコピーして、上記SQLにペーストします。

プロジェクトIDの確認方法

BigQueryの左上「Google Cloud」をクリック

ここにあります

SQLを実行する

select構文をつけて、実行します。

例 プロジェクトIDがaaa リージョンがUSの場合 

select * from `aaa.region-US.INFORMATION_SCHEMA.JOBS`;

実行すると、直近で実行したジョブ一覧が表示されます。

複数のクライアント様で確認したところ、おおむね半年程度のジョブが見れるようです。

次に、このジョブから、レガシーSQLのジョブを洗い出します。

先ほどの構文を、WHERE条件でGOOGLE_SQL以外(=レガシーSQL)に絞ります。

select * from `aaa.region-US.INFORMATION_SCHEMA.JOBS`
where query_dialect <> "GOOGLE_SQL";

以下のような結果にばれば、レガシーSQLは使っていません。

対応不要です。

同様の手順で、US以外のリージョンもチェックします。

例えば、asia-northeast1をご利用の場合、以下のように実行します。

select * from `aaa.region-asia-northeast1.INFORMATION_SCHEMA.JOBS`
where query_dialect <> "GOOGLE_SQL";

BigQueryのデータセットがUSのみの場合、チェック不要です。

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

Cloud Run 関数で処理がループする時の対処法

Cloud Run 関数で処理がループする時の対処法

・ETLでもよく使われるCloud Run 関数
・例えば、Google Cloud Storageに保存したエクセルをBigQueryに取り込んでテーブル化できる
・ただし、大量のエクセルを処理する等で、処理済みのエクセルが再処理され異常ループに陥りやすい
・処理済みのエクセルを退避フォルダへアーカイブすることでループを回避できる

ETLでGoogle Cloud Storageに保存したエクセルを、BigQueryでテーブル化する時に役立つのがCloud Run 関数です。

Cloud Run 関数は最近になって正式リリースされたもので、Google Cloud Functionsと聞けば、馴染みのある方も多いと思います。

現在、Google Cloud Functionsという製品ブランドは廃止され、Cloud Run Functionsという名前になりました。

そのCloud Run Functionsには第1世代と第2世代があり、いわゆる旧Google Cloud Functionsは第1世代にあたります。

第2世代が、今日ご紹介するCloud Run 関数というわけです。

もし、これから、ETL等でご利用される場合、Cloud Run 関数(旧Google Cloud Functionsの第2世代)の利用を強く推奨いたします。

第1世代は制約も多く、使えるメモリー等のパフォーマンスも劣ります。

大容量データを、複雑な処理でバッチ化する場合、第1世代ではタイムアウト時間も最大540秒と短く、処理が終わらずに停止するケースがよくあります。

第2世代なら、ハイパフォーマンスで処理できますので、様々なビジネス課題に対応することが可能です。

今日は、その最新のCloud Run 関数のお話です。

Cloud Run 関数の処理が異常ループする

例えば、Google Cloud Storage「バケットA」にエクセルが100個あるとします。

100個のエクセルを一括でBigQueryにテーブル化したい時、Cloud Run 関数が便利です。

たいていの場合、以下のようにsource_bucketを指定し、1回の実行で済むように、エクセルを1つ処理して、また次のエクセルを処理・・のようにループさせると思います。

#ソースバケットの指定
source_bucket_name = 'bucket_a'

~~~

blobs = list(source_bucket.list_blobs())

for blob in blobs:
source_blob_name = blob.name

~~~

しかし、このまま実行すると、一度処理したエクセルも再実行する異常ループが発生します。

エクセルが少なければ処理できると思います。

しかし、エクセルが100個あるような場合、この異常ループにより、処理が進まず、Cloud Run 関数がタイムアウトしてしまいます。

これは、「バケットA」にあるエクセルをすべて処理するまで、Cloud Run 関数が動き続けるためです。

ファイルが少なければ、異常ループが発生しても、すべてのファイルが処理される場合が多いのですが、ファイルが多い場合、異常終了してしまいます。

やっかいなことに、このように想定外で終了した場合も、Cloud Run 関数のエラーログにはErrorが吐き出されないため、LoggingやMonitoringの検知もすり抜けてしまいます。

つまり、未処理であることにユーザが気づきづらいのです。

処理済みエクセルはバケットBへアーカイブ。バケットAからも消す。

このような場合、Google Cloud StorageにバケットBを作り、処理したエクセルをバケットBへコピーしてアーカイブします。

そして、処理したエクセルもバケットAから消します。

これにより、すべてのエクセルは1度しか処理されず、異常ループは解消します。

バケットBへアーカイブせず削除してもかまいませんが、リカバリ等を考慮するとソースファイルは保護するのがベターです。

#ソースバケットの指定
source_bucket_name = 'bucket_a'
#アーカイブバケットの指定
archive_bucket_name = 'bucket_b'

~~~

blobs = list(source_bucket.list_blobs())

for blob in blobs:
source_blob_name = blob.name

~~


#処理済みファイルをアーカイブバケットにコピー
archive_bucket = storage_client.get_bucket(archive_bucket_name)
archive_blob = archive_bucket.blob(source_blob_name)
source_bucket.copy_blob(blob, archive_bucket, source_blob_name)

# ソースバケットから元ファイルを削除
blob.delete()
Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

BigQuery Data Transfer Service(DTS)の限界

BigQuery Data Transfer Service(DTS)の限界

・誰でも簡単にノーコードでBigQueryにデータ連携できることが魅力的
・例えば、Google Cloud Storageと連携すれば、CSVをアップロードする度にBigQueryも自動更新
・ただし、CSVのカラムを増やしたりするとエラーになる Excelも未対応
・工数はかかるが安定運用や長期的な工数を考慮すると、Cloud Runでフルスクラッチ開発がベター
・Cloud Runなら、カラムが変動しても、動的にBigQueryのテーブルを更新できる

BigQueryのようなDWHに社内外データを集約したい時に役立つのがBigQuery Data Transfer Service(DTS)です。

馴染みのない名前かもしれませんが、Google広告のデータをBigQueryに連携する時など、知らないうちに利用していたという方も多いと思います。

DTSは、たびたびアップデートされており、連携できるサービスも多数あります。

Google広告やYoutube、Google Cloud Storage(GCS)等のGoogle系サービスをはじめ、AWS(S3・Redshift等)やTeradata、最近ではSalesforceやMeta広告のプレビュー版が提供されています。

Salesforceのプレビュー版についてはこちらの記事もお勧めです。

AWS(Redshift)とBigQueryの連携についてはこちらの記事もお勧めです。

DTSのユースケース Google Cloud Storage(GCS)とBigQueryを連携

DTSで、よく使われているケースとして、GCSとBigQueryの連携があります。

特に、KPIをトラッキングする企業様において、目標値や実績等をCSVで管理されており、それらをBigQueryに連携して、他データと統合分析する場合に役立ちます。

実装もとても簡単です。

任意のCSVを用意します。1行目に変数名、2行目以降にデータを入力します。

GCSの任意のバケットにアップロードします。

アップロードしたCSVをクリックします。

このマークをクリックし、パスをコピーします。

BigQueryをひらきます。データセット横のマークをクリックし、テーブルを作成します。

テーブルの作成元「Google Cloud Storage」を選択し、GCSバケットの欄に、コピーしたGCSのパスをペーストします。

テーブルに任意の名前を入力します。画像加工によりプロジェクトがブランクになっていますが、プロジェクトはご自身のプロジェクト名が入ります。

スキーマをお好みで設定します。複雑なデータでなければ自動検出で可能です。

1行目をスキップし、変数名がデータとして取り込まれないようにします。

作成ボタンをクリックし、テーブルを確認します。成功すれば、このようにCSVが取り込まれます。

BigQueryの画面左「データ転送」→「転送を作成」をクリックします。

ソース「Google Cloud Storage」を選択し、任意の転送構成名を入力します。

データセットやGCSのCSV等を同じ要領で設定し、保存をクリックします。

設定が完了すると、画面が切り替わり、転送を開始します。

成功すると、緑色のチェックマークが点灯します。

DTSには限界もある

このように設定すると、CSVのレコードが増えても、GCSにCSVをアップロードしておけば、設定したタイミングでBigQueryに自動で反映します。

KPIをHourlyや日次で管理している企業様の場合、ノーコードで簡単な操作だけで、このようなデータ連携を構築できます。

しかし、DTSには限界もあります。

例えば、先ほどのCSVのD列にVar4を追加します。

GCSにアップロードし、上書きします。

DTSの画面で、今すぐ転送を実行します。これによりGCSのデータがBigQueryに手動で反映できます。

しばらくすると、処理がエラーになります。

エラーの内容です

Error while reading data, error message: CSV processing encountered too many errors, giving up. Rows: 0; errors: 3; max bad: 0; error percent: 0; JobID:...省略

many erros たくさんのエラーが発生し、正常に読み込まれたRowsレコードは0行です。

これは、CSVのカラムを増やしたことが原因です。

DTSは、CSVの仕様が変わると、このようなとエラーになります。

弊社のお客様には、社内データをCSVで管理されており、CSVのカラムを定期的に増やす企業様もおられます。

また、Excelで管理されている企業様もおられます。

そのようなケースの場合、DTSでは対応できません。

Cloud Runのフルスクラッチでカスタマイズ対応


このようなケースの場合、初期工数はかかりますが、Cloud Runのフルスクラッチ開発がベターになります。

Cloud Runなら、カラムが増えてもエラーにならず、動的にBigQueryのテーブルを更新できます。

特定セルの値だけBigQueryに取り込むことも可能で、Excelも取り込めます。

安定運用や長期的な工数軽減、柔軟に対応したい場合等を考慮すると、DTSより優れている場合が多いと思います。

Cloud RunはPythonに対応。様々なケースに応じた処理ができる。

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

GoogleのMMM「Meridian」を実装した印象と注意ポイント(後半)

GoogleのMMM「Meridian」を実装した印象と注意ポイント(後半) 

・分析レポートが秀逸 とても使い勝手が良い
・MMMの分析機能が向上 リーチとフリクエンシー等も反映できるようになった
・MMM Data Platformとの連携により、Google検索データも反映できるようになった
・ROIの事前分布をカスタマイズすることで、ビジネス知見の反映がより簡単になった
・カスタマイズにあたり注意すべきこともあるが、デフォルト利用でも十分に試しがいのあるツール
※2回にわけて投稿します。本記事は「MMM Data Platform」や「ROIの事前分布」等についてです。

 

LightweightMMM(Lwmmm)」の後継版となるGoogleの新しいMMM「Meridian」が一般公開されました。

Meridianについては、すでに多くのサイトで紹介されており、ご存じの方も多いと思います。

なるべく他のサイトと内容が重複しないように心がけておりますが、Meridianを実装した印象や注意ポイントについてまとめました。

前回は、Meridianの分析レポートの使い勝手や、新機能「リーチとフリクエンシーの反映」についてご紹介いたしました。

今回は、MMM Data PlatformROIの事前分布のカスタマイズ等についてご紹介いたします。

前回のお話は以下よりご覧いただけます。

「MMM Data Platformとの連携により、データ準備を効率化

MMMに限らず、分析の世界ではよく言われることですが、データ準備など、分析実行までの工程に多くのリソースを割かれます。

特に、MMMのように複雑な分析の場合、データ仕様も厳密に決められている場合が一般的です。

そのため、MMMを実行するうえで、一番ハードルが高いことは、適切なデータを準備することだと思います。

弊社クライアント様におかれましても、仕様を満たさないデータについて再作成をお願いするなど、データ準備に工数がかかる傾向にあります。

Meridianでは、そのようなMMMのつまづきポイントにもフォーカスしており、MMM Data Platformを使うことで、データ準備を効率化しています。

MMM Data Platformでは、Google Cloud StorageS3等のクラウドストレージにデータ連携できます。

データ連携によりデータ準備の工数を下げられますが、制約もあります(後述:「MMM Data Platformには制約がある)。

MMM Data Platform管理画面。画面左下の+ボタンからデータ連携を設定。

「MMM Data Platformとの連携により、Google検索データも反映できるようになった

機械学習等で精度の高いモデルを作る場合、データに大きく依存します。

つまり、どれだけ良いデータを集めて、質の良い特徴量(変数)等をモデルに読み込ませるかが、とても大事です。

これは、MMMにおいても同様です。

広告のメディアデータに加えて、マーケット自体の盛り上がりなど外部要因を考慮することで、精度の高いモデルに近づく可能性が高まります。

検索データは、そのような外部要因を考慮するうえで役立つデータです。

MMM Data Platformとの連携により、検索データが使えるようになったことで、その可能性はさらに高まります。

そのようなモデルに仕上げることで、自社の売り上げUPが、自社の広告効果なのか、もともとマーケット需要が高かったのかを見極め、純粋な広告効果を推定できることにつながります。

しかし、Meridianの実装において、注意すべきことがあります。

「Google検索データを使わないほうが良いケースもある

Meridianのドキュメントには「因果推論」という言葉が何度も出てきます。

これは、見かけによる広告効果ではなく、広告による純粋な売上UPを推計しようとする考え方です。

MMMの目的は因果推論

因果推論において、検索データの扱いが大事であることもドキュメントに書かれています。

この点において注意が必要です。

検索データを使わないほうが良いケースがあります。

ドキュメントでは、検索データをモデルに使うべきかについて、客観的な数値基準に基づいた確定ルールは存在せず、ユースケースによって判断とあります。

ドキュメントのコントロール変数の概要図。これを見ても、検索データをモデルに使うべきか判断しづらい。

「検索データを使ったほうが望ましいと考えられるケース

そこで、クリスマス商戦を例に、検索データをモデルに使うべきか検討します。

例えば、クリスマス商戦では「クリスマスプレゼント」の検索クエリが多く発生します。

それを狙って、検索広告の予算も通常月より増えるので、検索広告も多く発生します。

広告費は需要の変動に応じて連動し、そのぶん売上も連動します。

需要の増加と広告費の増加が一致してしまい、純粋な広告効果を推計しづらくなります。

このような場合、検索データを使ったほうが良いと考えられます。

検索ボリュームが、検索広告と売上それぞれに対して、どの程度影響するかわかることで、純粋な広告効果を推定できるためです。

このケースの検索データはConfounding Controls(交絡変数)。モデルに使うことを推奨。Treatmentは効果を評価したい広告。

「TVCM等で検索喚起を狙っている場合は注意が必要

検索データを使わないほうが良いケースも考えられます。

例えば、TVCMを大量投下し、認知獲得や検索喚起を狙う場合です。

このような場合、検索データを使ってしまうと、TVCMの広告効果を適切に評価できない可能性があります。

TVCMにより、検索が喚起され、検索ボリュームが増えます。

検索クエリが多く発生すると、検索広告も多く表示され、そのぶん売上も連動します。

TVCMにより検索が喚起されましたが、検索データをモデルに組み込むことで、検索データが評価され、TVCM本来の効果が評価できない可能性があります。

このような場合、検索データを使わないほうが良いと考えられます。

このケースの検索データはMediator Controls(メディエーター変数)。モデルに使わないことを推奨。インフルエンサー施策による検索喚起も同様。

これらの判断に際し、ドキュメントでは、次のようにアドバイスしています。

検索ボリュームを交絡因子と判断してモデルに含めるか、メディエーターと判断してモデルから除外するかを決める必要があります。どちらの仮定を選ぶか決める際のポイントは次のとおりです。

・バイアスのない推定値を得るうえで重要度の高いチャネル
・介入群、検索ボリューム、KPI の想定される相関性の強さ
・検索ボリュームがメディエーター変数ではなく交絡変数であるチャネルの推定数

まさに、前述のユースケースによって判断というわけです。

例えば、1つ目の「バイアスのない~」は、どのメディアの評価を優先するかということです。

先ほどの例の場合、もし、検索広告がマーケティングの重要チャネルで、検索広告を正しく評価したいなら、検索データをモデルに使うことを検討します。

反対に、TVCMの評価を優先したいなら、検索データを使わないことを検討します。

このように、広告主側の意向や各メディアと検索の関係等を総合的に考慮して、ケースバイケースで決めることをGoogleは推奨しています。

「ROI事前分布のカスタマイズもできる

Meridianでは、ビジネス知見を反映しやすい機能も実装されました。

Lwmmmでは、ROI以外の事前分布等を調整することで、ROIやモデルを最適化していましたが、その調整が他の要素とも相互作用してしまい、最適化が難しい側面がありました。

Meridianでは、ROIを直接モデルのパラメータに指定できるようになり、ビジネス知見に基づいた直感的で柔軟なモデル調整が可能になりました。

このUpdateにより、モデル精度がどの程度高まったかについて、Googleの論文に記載されています。

この図は、ROI事前分布の実装有無により、モデル精度がどの程度改善したかを示しています。

太い赤線が真のROI(正解)で、他の3色の線は実験パターンです。
青:従来のモデル。ROI事前分布なし。
オレンジ:Meridian。ROI事前分布あり(全期間)。
緑:Meridian。ROI事前分布あり(一部期間のみ)。

赤線に近いほど、モデルの精度が高く、安定しています。

青の従来のモデルは、横に広がっており、推定のバラツキが大きく、赤線から遠く離れています。

一方、Meridianは、推定のバラツキが小さく、赤線に近いことから、より正確なROIを推定できていることがわかります。

オレンジ(全期間)が最も赤線に近いことから、長期のデータを使うことで、より精度が高まるようです。

Meridianでは、このROI事前分布を任意に設定できます。

分布と表現すると、馴染みがないかもしれませんが、平均とバラツキになります。

Meridianではメディア別にROI事前分布を指定できる。roi_m_mu、roi_rf_muが平均。roi_m_sigma、roi_rf_sigmaがバラツキ。rfが付いているものはリーチとフリクエンシーが取れるメディア。

ただし、ここで入力する数字は、一般的な平均とバラツキではありません。

ここで入力されたROI分布は、Lognormalという分布で処理されます。

Lognormalで処理する数字は、一般的な平均とバラツキではなく、対数平均・対数標準偏差になります。

ROIは、一般的にマイナスを想定しておらず、正の値をとります。

通常の分布で実装するとマイナスがありえることから、このような分布を仮定しています。

Lognormalは、対数平均と対数標準偏差を処理。ROIが正の値となり、マーケティング分析に適している。

この2つの数字を入れると、ROIの中央値や平均等が計算できます。

事前分布がわからない場合、ドキュメントでは、対数平均0.2・対数標準偏差0.9を推奨しています。

この数字を、ROIに換算すると、以下になります。

Meridianでは、何も指定しない場合、ROI平均1.83(183%)で想定しています。

標準偏差も2.05(205%)と、大きなバラツキが設定されています。

しかし、実際の運用においては、メディアごとにROIが異なります。

MeridianのデフォルトであるROI平均1.83を超えるメディアや、反対に下回るメディアもあります。

バラツキについても同様です。

メディアごとに安定性が異なるのが通例でしょう。

このように、実際の運用における実績が明らかな場合、ROI事前分布をカスタマイズすることを推奨いたします。

カスタマイズにより、どの程度結果が変わるか試してみました。

例えば、初回の分析で以下の結果が得られたとします。※数字はダミーです

このグラフは、MeridianのROIの分析結果です。

Channel0が最良で、Channel3が最も不芳と評価されました。

次に、Channel3を最良なメディアに変えてみます。

Channe3のROI事前分布を以下のようにカスタマイズします。

換算後のROIは平均約700%で、それに対してバラツキは小さく、安定し高成果の良好なメディアです(こんなメディアは、なかなかお目にかかれませんが)。

この条件で再実行すると、以下のように結果が変わり、Channel3が最良なメディアになりました。

カスタマイズ前のROI

Channel3のROI評価は1.5(150%)

カスタマイズ後のROI

Channel3のROIが大きく向上。本来あるべき評価に。

このように、Meridianでは、ビジネス知見をROI事前分布としてモデルに反映することで、ビジネス知見に基づいた直感的で柔軟なモデル調整が可能になりました。

それにより、Lwmmmよりも、正確に広告効果を検証できます。


レポート出力やMMM Data Platformの制約など、Meridianを実装するうえでの注意ポイントが他にもあります。

「Colab Enterpriseでインストールガイドにそって進めると、レポートを出力できない

MeridianはPythonで動作します。

インストールガイドは、Google Colab(Colaboratory)を想定していると思われます。

Google Colabは、気軽にPythonのNotebookを構築できますが、ファイル単位等でのアクセス管理になります。

クライアント様からデータをお預かりする企業側としては、セキュリティ面でやや不安があります。

一方、企業向けを想定したColab Enterpriseなら、費用はかかりますが、セキュアなGoogle Cloudで実行できます。

Google Cloudでは、IAM(Identity and Access Management)で細かくアクセス制御できます。

Colab Enterpriseなら、Google Colabのような使い勝手そのままで、セキュアな環境でNotebookを実行できるというわけです。

弊社の開発環境はGoogle Cloudにあります。

Meridianについても、Google CloudのColab Enterpriseで実装しています。

インストールガイドには、Googleドライブにモデルの結果を出力する説明があります。

しかし、Colab Enterpriseでドキュメントのプログラムを実行するとエラーになるかと思います。

NotImplementedError: google.colab.drive.mount is not supported in Colab Enterprise.

これは、Colab Enterprise では google.colab.drive.mount() を使用できないことが原因です。

このような場合、Meridian用にGoogle Cloud Storageをたてて、サービスアカウントを発行し、IAMで権限を付与してアクセスキーや認証情報を使って、Google Cloud Storageにレポートを出力することで回避できます。

「MMM Data Platformには制約がある

Meridianでは、MMM Data Platformを使って、Google検索データやGoogle広告のリーチとフリクエンシーをGoogle Cloudに連携できます。

しかし、制約がありますのでご注意ください。

申請が必要。すぐには使えない。3営業日が目安。
MMM Data Platformの利用は申請が必要です。3営業日を目安にGoogleからアカウントについて連絡がきます。連絡が届いた後、データ連携を設定し、約2週間でデータが納品されます。

広告主、または、一部の代理店等のみ直接連携が可能
広告主か、GoogleのMMMパートナープログラムに参加しているサードパーティのみ、MMM Data Platformへ直接連携が可能です。Google広告を利用している広告主様であれば特段問題ございません。

MCC IDは不可。
MCC ID(マネージャーアカウントID)は連携できません。

リーチとフリクエンシーはYoutubeキャンペーンのみ可能。
Google広告のリーチとフリクエンシーを連携できますが、現時点ではYoutubeキャンペーンのみ可能です。他の広告キャンペーンについては、Google広告管理画面等からデータを集めることになり、一定の工数がかかります。これは残念な仕様ですね。改善が待たれます。

Google検索データは生の検索数ではない。
MMM Data Platformで取れる検索データは、生の検索数ではありません。Googleトレンド同様の指数化されたデータです。指数化されていますが、このデータはコントロール変数として使用します。指数化してもモデルには影響しません。

たしかに、ドキュメントには「検索ボリューム」とあります。「検索数」とは書かれていません。

Google Cloud開発お承ります

datacompanyでは、Meridianの受託分析をはじめ、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

GoogleのMMM「Meridian」を実装した印象と注意ポイント(前半)

GoogleのMMM「Meridian」を実装した印象と注意ポイント(前半) 

・分析レポートが秀逸 とても使い勝手が良い
・MMMの分析機能が向上 リーチとフリクエンシー等も反映できるようになった
・MMM Data Platformとの連携により、Google検索データも反映できるようになった
・ROIの事前分布をカスタマイズすることで、ビジネス知見の反映がより簡単になった
・カスタマイズにあたり注意すべきこともあるが、デフォルト利用でも十分に試しがいのあるツール
※2回にわけて投稿します。本記事は「分析レポート」と「リーチとフリクエンシー」についてです。

先月末、Googleの新しいMMM「Meridian」が一般公開されました。

従来の「LightweightMMM(Lwmmm)」の後継版とされています。

Lwmmmにはない機能も新たに実装され、大幅なモデルチェンジとなっています。

Meridianについては、すでに多くのサイトで紹介されており、ご存じの方も多いと思います。

なるべく他のサイトと内容が重複しないように心がけておりますが、Meridianを実装した印象や注意ポイントについてまとめました。

「ビジネス的にもエンジニア的にも、とても使い勝手の良いツール」

Meridianを実装した印象は「とても使い勝手の良いツール」ということです。

リーチとフリクエンシーを反映できるなど機能面はもちろんですが、データエンジニアの観点においても、Lwmmmより実装が容易でした。

例えば、Lwmmmの実装には、ドキュメントやGithubから必要なプログラムを精査し、実装とエラーを試行錯誤していたと思います。

一方、Meridianは、効率的な設計になっており、モデル仕様や実装類のドキュメントも充実しています。

インストールガイドに従うだけで、デフォルト仕様であれば容易に実装できます。

また、レポートもとても見やすいです。

Lwmmmでは、基本的に図表類はPNG出力でしたが、Meridianではhtmlファイルで出力されます。

このhtmlファイルがとても素晴らしく、MMMの分析結果が綺麗にまとまっています。

視認性も高く、社内共有等にも適した仕様です。

Meridianのグラフの1つ。予算の最適化前後のRevenueが容易にわかる。htmlファイルでオンマウスに対応。

PNG出力等もできる。

英語で出力されるがchromeの翻訳機能を使えば読み解ける。

いくつかサンプル画像をとりあげましたが、実際にレポートを見ていただくと、Meridianの優れたポイントを感じていただけると思います。

Meridianのサンプルデータを使ったMMM分析レポートをアップロードしました。

新機能のリーチとフリクエンシーを反映したレポートです。

ぜひご覧ください。Meridianのレポートは2つ出力されます。

※PCから閲覧を推奨します。スマートフォンの場合、横向きにすると比較的見やすいです。

「リーチとフリクエンシーを反映できる

まず、Lwmmmから大きなUpdateとしては、リーチとフリクエンシーを反映できることです。

Lwmmmでは、インプレッションをモデルに反映できますが、リーチとフリクエンシーは反映できません。

例えば、インプレッションが100の場合、「1人に100回配信」「50人に2回ずつ配信」どちらのケースもありえますが、Lwmmmはリーチとフリクエンシーを反映できないため、どちらも同じものとして評価します。

Lwmmmにおいても、Hill関数等で広告効果のサチレーションを反映できますが、仮に、「50人に2回ずつ配信」だった場合、サチレーションは発生しづらいと考えるのが妥当です。

そのため、Lwmmmでは、これらを考慮できないことが弱点の1つとされていました。

一方、Meridianでは、リーチとフリクエンシーをモデルに反映できるようになりました。

これにより、Lwmmmより高い精度で分析が可能になりました。

サチレーションや最適なフリクエンシーが簡単にわかることで、広告運用者がキャンペーンを最適化しやすくなりました。

このUpdateにより、モデル精度がどの程度高まったかについて、Googleの論文に記載されています。

左側の表がリーチとフリクエンシーを反映したモデルです。右側が従来のモデルです。

モデル精度指標の1つであるR2で評価し、すべてのパターンにおいて精度が高くなっています。

また、Train(教師データ:モデルを作るデータ)と、Test(評価データ:モデルを評価するデータ)との比較において、従来のモデルより安定していることがうかがえます。

従来のモデルは、Geo(地域別)ではTest精度が下がりますが、National(全国)では反対にTest精度があがっています。

機械学習等でモデルを作る場合、Testも精度がぶれず、安定したモデルを作ることが大切ですが、従来のモデルは少しぶれています。

一方、Meridianはリーチとフリクエンシーを反映することで、モデル精度が安定していることがわかります。

式を見ると、Meridian(上の式)は、Hill関数※1でフリクエンシー※2を処理していますが、リーチ※3は処理していません。
※1 式の真ん中あたりHill。広告効果のサチレーションを計算する関数。
※2 Hill関数の右となりf
※3 Hill関数の左となりr

リーチはHill関数の外側にあり、リーチとフリクエンシーの処理をわけています。

MAPEを使わずR2のみで精度評価していることや、リーチをHill関数で処理しない≒リーチとKPIの関係を線形で想定していること等について議論の余地はあるかもしれませんが、このような仕組みで、インプレッションでサチレーションを計算するLwmmmより精度が高くなります。

このようにお伝えすると、「全メディアのリーチとフリクエンシーを入手できるかわからない」とご心配されるかもしれません。

ご安心ください。全メディア対応がマストではありません。

Meridianでは、入手できるメディアについては、リーチとフリクエンシーを使い、入手できないメディアはインプレッションで分析できるように自動で処理されます。

この論文を見る限り、先ほどの式で例えると、入手できないメディアの場合、フリクエンシーfをインプレッションに置き換え、 リーチr を 1 に置き換えるような処理(結果的に従来のモデルと同じ)をしていると思われます。

また、リーチとフリクエンシーを使う場合、インストールガイドにそってプログラムを修正する必要がありますが、以下のようにリーチとフリクエンシーを入手できるメディアを追加する形式で扱いやすいです。

もし、リーチとフリクエンシーを入手できるメディアがあれば、利用されることを強く推奨いたします。

リーチとフリクエンシーを処理するプログラムの一例。correct_media_to_channelでインプレッションのメディアを処理し、correct_reach_to_channel 以降のプログラムでリーチとフリクエンシーのメディアを処理。

前半はここまでになります。

後半に続きます。

Google Cloud開発お承ります

datacompanyでは、Meridianの受託分析をはじめ、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

Looker Studioが重くなる理由と解決方法

Looker Studioが重くなる理由と解決方法

・Looker Studioが重くなりやすいのはスプレッドシートやCSV等のソースデータ
・特に、スプレッドシートは、KPI集計を重視している企業様ほど重くなりやすい
・スプレッドシートの特性を理解したうえでスリム化
・スリム化できない場合、Google BigQueryにスプレッドシートを取り込み内部テーブルに変換

Googleサーチコンソールを見ていると、どのような検索キーワードで弊社サイトに訪問されているか、傾向がある程度わかります。

そのなかで、ある検索キーワードで訪問される方が常に一定数いらっしゃいます。

それは「LookerStudioが重い」というお困りごとです。

「LookerStudioが重い!軽くしたい!」

弊社のお客様からも頻繁にご相談いただくもので、世界共通のLookerStudioあるある話かもしれません。

特にスプレッドシートを活用して、KPI集計を重視されている企業様ほど、LookerStudioが重くなる傾向にあるようです。

弊社のお客様には、KPI集計を重視されている企業様が多いです。

業態にもよりますが、特に、社内横断で売上データを共有されていたり、頻繁に更新する必要がある企業様においては、直感的に操作できて、数字も管理しやすいスプレッドシートが大活躍します。

スプレッドシートでKPI集計は限界がある

ただ、スプレッドシートで運用には限界があります。

スプレッドシートをご利用の方ならイメージしやすいと思いますが、レコード数やカラム数、関数、シート数が増えるほど、スプレッドシートの操作は重くなる傾向にあります。

一般的に、シート数は複数枚になることが多く、弊社のお客様において、スプレッドシート1枚のみで運用されていたことは1社様もありません。

複数枚のシートを使い、シート間を関数で参照・接続・・・といった使い方になりますが、この使い方は便利な反面、スプレッドシートの操作を重くする一因になります。

また、同時に、複数の方が編集することで拍車がかかります。

スプレッドシートは表計算が得意ですが、グラフや表などでグラフィカルに描画したり、スムーズ・動的にKPIをチェックする点おいては、圧倒的にLookerStudioが優位になります。

このように、スプレッドシートは便利ですが、ある程度のレベルまで来ますと、スプレッドシートでKPI集計は限界があります。

スプレッドシートをLookerStudioのデータソースとするデメリット

このような場合、スプレッドシートをLookerStudioのデータソースとして参照し、BI側でKPI集計することがほとんどです。

しかし、このようなスプレッドシートを参照してしまうと、LookerStudioの操作感にもネガティブに影響します。

スプレッドシートのレコード数やカラム数、関数、シート数が増えるほど、LookerStudioの操作感も重くなる傾向にあります。

LookerStudioの描画が重くなり、もたつきが目立つようになると、データロードに時間がかかり、KPIをスムーズに集計できなくなります。

これは、とてもストレスフルなことです。

スプレッドシートを軽くできないか検討する

まずは、スプレッドシートを軽くできないか検討します。

述べた通り、スプレッドシートのレコード数やカラム数、関数、シート数が増えるほど、重くなります。

不要なシートやカラム削除し、関数もなるべく減らすことにより、ある程度は軽くすることができます。

しかし、この方法は、あまり現実的ではありません。

それは、KPI集計を重視されている企業様ほど、スプレッドシートを日常的に効率化されており、不要なシートやカラム等がほとんど見つからないためです。

また、スプレッドシートをBigQueryに連携済みで、LookerStudioのデータソースをスプレッドシートからBigQueryに変更済みであることがほとんどです。

BigQueryにスプレッドシートを取り込み内部テーブルに変換を検討する

このような場合、大きな効果を得られるのが、BigQueryを使った内部テーブルへの変換です。

BigQueryのデータは外部テーブルと内部テーブルがあります。

外部テーブルは、BigQueryの外側にあるデータです。

スプレッドシートはGoogle Driveにあり、BigQueryの外側にあります。

そのため、BigQueryでテーブル化したスプレッドシートも外部テーブルになります。

BigQueryのテーブル作成画面。スプレッドシートは外部テーブルと表示される。

スプレッドシートをBigQueryのテーブルとして簡単に取り込めますが、このままでは解決しません。

外部テーブルはBigQueryの内部ストレージの外側にあり、内部テーブルよりアクセスビリティが劣ります。

そこで、この外部テーブルを内部ストレージに取り込むことで内部テーブルに変換し、アクセスビリティを高めて、LookerStudioの操作性を改善します。

手順は以下の通りです。とても簡単です。ぜひお試しください。

・BigQueryで、外部テーブルを内部テーブルに変換するプログラム(SQL)を作成
・スケジュール化して定期実行

プログラム例

CREATE OR REPLACE TABLE
`プロジェクト名.データセット名.外部テーブルの名前` AS
SELECT
*
FROM
`プロジェクト名.データセット名.スプレッドシートを取り込んだ内部テーブルの名前`
;

BigQuery 外部テーブルとは

BigQuery 内部テーブルとは

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

Googleのチュートリアル通りに進めるとエラーになるときの対処法

Googleのチュートリアル通りに進めるとエラーになるときの対処法

・エラーメッセージから仮説を立て試す
・チュートリアルに記載のないことも試す
・特に、プレビュー環境の場合、チュートリアルが実態にそっていない傾向があることを知っておく
※執筆当時の情報です

前回は、Cloud Data Fusionを停止して年間200万円コスト削減したことをご紹介いたしました。

今回は、Amazon RedshiftからGoogle BigQueryへデータ連携を事例に、Google Cloudのチュートリアル通りに進めてもエラーになる場合の対処方法をご紹介いたします。

前回のお話は以下よりご覧いただけます。

Googleの公式サポートを使わずに解決できればベター

Google Cloudのチュートリアルは、ほぼ完全に整備されており、チュートリアルを進めることで大抵のことは解決します。

あまり経験していませんが、チュートリアル通りに進めてもエラーになる場合があります。

そのような場合、Google Cloudの公式サポート(有償)を頼ることになりますが、この事例で取り上げるCloud Data Fusionの日本サポートチームはインドのバンガロールにあります。

時差や英語でのコミュニケーションに加え、オンライン会議で画面操作を試す→エラー→再操作→再エラー・・・を繰り返すなど、効率が良いとは言えず、とても多くの工数を消費してしまいます。

また、事前にチケットで、プログラムや出力結果を送っているものの、担当チームやメンバーによっては、会議で初めて内容を確認されたり、仮説を持ち寄らず、場当たり的に複数人から操作を求められる・・・といったこともありました。

なるべく公式サポートを使わずにエラーを解決できるのがベターですので、今回のお話が皆様にもご参考になれば幸いです。

Amazon RedshiftとGoogle Cloudの連携

クライアント様がAWSからGoogle cloudにクラウド移管をご検討中で、AmazonのDWHであるRedshiftから、Google CloudのDWHであるBigQueryにデータ移管を準備していました。

RedshiftからBigQueryに連携する方法はいくつかありますが、今回のご要望の場合、BigQueryのデータ転送APIであるBigQuery Data Transfer Service(DTS)を使うことが最も簡単です。

DTSによるデータ連携は、Redshiftへの直接連携ではなく、下図のようにAWSのクラウドストレージS3を介して連携されます。

DTSでRedshiftに連携すると、S3を介して連携。S3はステージング領域として使用。

Amazon Redshift からスキーマとデータを移行する

この設定には、AWS側の情報やアクセス権限等が必要です。

クライアント様は代理店様を通じてAWSをご契約されており、AWSの管理も代理店に任せておられました。

クライアント様にお願いし、代理店様から情報一式をいただきましたが、Amazon IAM ユーザーの情報が見当たりませんでした。

クライアント様に確認したところ、IAMユーザについてはクライアント様もお持ちでなく、わからないとのことでした。

そこで、代理店様に確認したところ、代理店様の社内規定により、クライアント様や弊社にはIAMユーザーを引き渡せないとの回答でした。

一般的には、委託元もIAMユーザを使えるのですが、クライアント様と代理店様の契約上の理由とのことで、予定していたDTSによるデータ連携を断念しました。

DTS以外でRedshiftとBigQueryを連携

DTS以外でもRedshiftとBigQueryを連携できます。

網羅できておりませんが、例えば、以下の方法があります。

一番上のDTSは、AWSのIAMユーザーが必要なため、断念した方法です。

方法AWS IAMユーザー
BigQuery Data Transfer Service(DTS)必要
BigQuery Omni必要
Cloud Data Fusion不要

2つ目のBigQuery Omniは、AWSのS3を外部データソースとしてBigQueryから参照し、SQLを実行できるものです。

RedshiftからS3へのデータコピーは必要ですが、BigQueryへのデータコピーは不要です。

しかし、この方法もAWS IAMユーザーが必要で、今回の要件を満たしません。

また、現在、東京リージョンに非対応です。

クライアント様にご相談したところ、納期が最速で、安定稼働できることをお求めでしたので、Cloud Data Fusionで進めることになりました。

Cloud Data Fusionは、バックエンドでクライアント様専用の仮想サーバを立ててパイプラインを構築するようなもので、時間課金のETLツールです。

1年間利用すると、現在の為替レートで約200万円課金されますが、今回のご要望のように、クラウド移管に際して一時利用であれば、デフォルトで用意されているGoogle Cloud の月間無償枠で利用できます。

チュートリアル通りに進るとエラーになる

チュートリアルを見ると、あらかじめ、AWSのJDBCドライバーをCloud Data Fusionにアップロードしておく必要があります。

HostやPortなど、その他の必要な情報をクライアント様・代理店様から入手し、設定しました。

Cloud Data Fusionでは、設定が正しいか、デプロイ前にVaridateボタンを押下すると検証できます。

ところが、ボタンを押下したところ、Read timed out という見慣れないエラーが出ました。

一時的なものかと思い、何回か試しますが、結果は変わりません。

AWS側のマニュアルを見ると、JDBCドライバーのオプションとして、timeoutに関する設定を変更できるようです。

そこで、Cloud Data Fusionでこれらの変数を設定して、timeoutを無効にしました。

0(無効)、7200秒(2時間)でtimeoutパラメータを設定

しかし、結果は変わりません。

Read timed outでタイムアウトエラーになります。

チュートリアルどおりに進めているのにデプロイできずエラーになります。

ここで、解決策が尽きてしまいました。

エラーメッセージから仮説をたて試す

Read timed outというエラーメッセージからすると、Redshiftにデータを参照している際に発生するエラーのようです。

一般的には、データ容量が大きくなるほど、連携に必要な時間も長くなります。

カラム(列)が増えると、データ量も急激に増え、時間も長くなります。

そこで、1カラムだけ連携したところ、Varidateが成功し、デプロイできました。

次に、カラムを2カラムで試すと、Read timed outのエラーになりました。

どうやら2カラム以上だとTimeoutするようです。

そこで、レコード数がどの程度までなら、2カラムでもデプロイできるか確認することにしました。

10レコード程度で2カラムのサンプルデータをRedshiftに用意し、Varidateしたところ、Timeoutしました。

デプロイに成功した1カラムのデータは、1000レコード以上あります。

Timeoutした2カラムのサンプルデータは10レコードです。

このTimeoutエラーは、データ量ではなく、設定など別の理由が原因と仮説を立てました。

どの設定が原因か特定するため、1つずつ設定内容を変えてみることにしました。

例えば、JDBC接続に必要なAWS側のパスワードを、故意に1文字減らしました。

そうすると、エラーメッセージが変わり、Timeoutは表示されません。

これにより、パスワードは正しく、パスワード以外の方法が原因であるこことがわかります。

このような地味なチェックを進めたところ、Output Schemaを自動判定させず、手動入力してからVaridateすると、デプロイできました。

チュートリアルではVaridateで自動判定するOutput Schema。今回の事例では、この機能が原因でエラーに。

チュートリアルでは、手動入力ではなく、Varidateで自動判定させますので、思いもよりませんでした。

Google Cloudのチュートリアル通りに進めてもエラーになる場合、このように進めると突破できる可能性があります。

プレビュー環境の場合、チュートリアルが実態にそっていない傾向がありますので、より一層ご留意ください。

・エラーメッセージから仮説を立て試す
・チュートリアルに記載のないことも試す
・特に、プレビュー環境の場合、チュートリアルが実態にそっていない傾向があることを知っておく

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

法人登記、ならびに、利用規約改定のお知らせ

平素より、datacompanyをご愛顧いただき、誠にありがとうございます。 
このたび、2024年12月2日(月)に法人化したこと等に伴い、利用規約を改定いたしましたので、お知らせいたします。

・規約改定について
改定日:2024年12月2日(月)
主な改定事項:datacompanyを「株式会社datacompany」としました。

改定後の規約については以下よりご確認いただけます。
規約

会社概要については以下よりご確認いただけます。
会社概要

今後ともdatacompanyをよろしくお願いいたします。

SalesforceとBigQueryを連携 プレビュー環境で年間200万円削減

SalesforceとBigQuery連携
プレビュー環境で年間200万円削減

・Cloud Data FusionからBigQuery Data Transfer Serviceに切り替え
・Cloud Data Fusionの年間コスト200万円を削減
※執筆当時の情報です。Basic月間利用費$1,100、為替レート150円で計算したものです

「SalesforceとBigQueryを連携したい」というご要望が多いことから、このページをご覧の皆様も、「あること」にお困りではないかと思います。

それは「連携コストが高すぎる」ことです。

Cloud Data Fusionは利用費が高い

SalesforceとBigQueryを連携する方法はいくつかありますが、最も簡単でメジャーな方法はCloud Data Fusionです。

Cloud Data Fusionは、外部ソースとGoogle Cloudを連携できるノーコードツールで、ETL / ELT パイプラインを簡単に構築できます。

Cloud Data Fusion公式

しかし、ノーコードで簡単にできるものの、本番運用に適したBasic以上の利用料は月間約$1,100~と高額で、$1=150円として月16.5万円、年約200万円もかかります。

しかもこの料金、連携するデータ量が0ゼロであっても発生します。それは、Cloud Data Fusionの仕組みに理由があります。

Cloud Data Fusionでパイプラインを構築するためには、最初にインスタンスを立てなければなりません。

皆様専用の仮想サーバをGoogle Cloud に1つ立てるようなものとイメージいただければと思います。

このインスタンスが時間課金となっており、連携するデータ量が0ゼロであっても料金が発生するというわけです。

Cloud Data Fusion料金公式

連携を開始してから、しばらくの間、たいていのお客様はデータ連携を自動化できたことで喜ばれます。

しかし、事前に料金のことをわかっていたとしても、Googleからの高額請求が続きますと、「コストカットできないものか・・・」とご相談をいただくケースが多いです。

過去には「毎月1日だけインスタンスを作り、データ連携後にインスタンスを削除できないでしょうか」といったご相談をいただいたこともありました。

しかし、その方法では、Salesforceのデータ鮮度が落ちてしまい、本業への影響が大きく、断念されておられました。

SalesforceとBigQueryを直連携!

2024年3月Googleは「BigQuery と Salesforce Data Cloud 間の双方向データ共有が一般提供開始」とリリースしました。

これにより、Cloud Data Fusionなしで、SalesforceとBigQueryを連携できるようになりました。

現在、この機能はプレビュー版として提供されており、料金も無料です。

パイプラインを切り替えるだけで、年間200万円のコストが削減できます。

プレビュー版とは、本番リリース前のテスト環境のようなものです。

プレビュー版にはGoogleのSLAもございませんが、現時点で問題なく稼働しており、Cloud Data Fusionに戻されたお客様は一社様もございません。

Googleプロダクトステージ公式

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

News

BigQuery レガシーSQLを使用しているジョブを洗い出す

2025年8月1日から、GoogleSQLがBigQueryのデフォルト言語になることがGoogleより発表されました。 今後も、レガシーSQLを使う場合、オプション等で明示的に指定する必要があります。 レガシーSQLを …

Cloud Run 関数で処理がループする時の対処法

ETLでGoogle Cloud Storageに保存したエクセルを、BigQueryでテーブル化する時に役立つのがCloud Run 関数です。 Cloud Run 関数は最近になって正式リリースされたもので、Goog …

BigQuery Data Transfer Service(DTS)の限界

BigQueryのようなDWHに社内外データを集約したい時に役立つのがBigQuery Data Transfer Service(DTS)です。 馴染みのない名前かもしれませんが、Google広告のデータをBigQue …

GoogleのMMM「Meridian」を実装した印象と注意ポイント(後半)

  「LightweightMMM(Lwmmm)」の後継版となるGoogleの新しいMMM「Meridian」が一般公開されました。 Meridianについては、すでに多くのサイトで紹介されており、ご存じの方も多いと思い …

GoogleのMMM「Meridian」を実装した印象と注意ポイント(前半)

先月末、Googleの新しいMMM「Meridian」が一般公開されました。 従来の「LightweightMMM(Lwmmm)」の後継版とされています。 Lwmmmにはない機能も新たに実装され、大幅なモデルチェンジとな …

Looker Studioが重くなる理由と解決方法

Googleサーチコンソールを見ていると、どのような検索キーワードで弊社サイトに訪問されているか、傾向がある程度わかります。 そのなかで、ある検索キーワードで訪問される方が常に一定数いらっしゃいます。 それは「Looke …

Googleのチュートリアル通りに進めるとエラーになるときの対処法

前回は、Cloud Data Fusionを停止して年間200万円コスト削減したことをご紹介いたしました。 今回は、Amazon RedshiftからGoogle BigQueryへデータ連携を事例に、Google Cl …

法人登記、ならびに、利用規約改定のお知らせ

平素より、datacompanyをご愛顧いただき、誠にありがとうございます。 このたび、2024年12月2日(月)に法人化したこと等に伴い、利用規約を改定いたしましたので、お知らせいたします。・規約改定について改定日:2 …

SalesforceとBigQueryを連携 プレビュー環境で年間200万円削減

「SalesforceとBigQueryを連携したい」というご要望が多いことから、このページをご覧の皆様も、「あること」にお困りではないかと思います。 それは「連携コストが高すぎる」ことです。 Cloud Data Fu …