広告費が効かない・計測が信用できない

広告運用 AI ダッシュボード — 複数案件×4媒体の日次自動レポーティング

単一基盤とマルチテナント認証で共通ダッシュボード化

業種・関与mixednuts 自社基盤/複数クライアント共通 · マーケティング/AI インフラ · AI · MARKETING

対応媒体

4 媒体

データ統合

4 ソース統合

認証基盤

マルチテナント

課題

mixednuts 配下で複数の広告案件が並走している中で、案件ごとに異なる計測環境(ECCUBE / Shopify / Graphene)・媒体構成・CV 定義を人手で束ねる運用は持続不可能だった。Looker Studio や Sheet ベースの簡易ダッシュボードでは、クライアントに見せる UI 品質と、セキュリティ(他クライアントのデータ漏洩リスク)の両立が難しい。自社で共通基盤を作り、案件横展開することが最もレバレッジが効く判断に至った。

複数の広告案件を並行運用していると、クライアントごとに異なる計測ツール・媒体・CV 定義でレポートを組み直す工数が膨大になる。Sheet 手作業 → 翌週定例という従来サイクルでは意思決定が遅れ、異常値の発見も遅延する。案件ごとに別ダッシュボードを開発するのも非効率。

  • 案件ごとに計測ツール(ECCUBE / Shopify / Graphene)と媒体構成(Google のみ / 4媒体)が異なり、Sheet や BI ツールの横展開が困難
  • クライアント別に URL / 認証を分け、他クライアントの存在すら見せない Multi-tenant 要件
  • 手作業レポートは週次定例に間に合わせるのが律速で、異常値検知が数日遅れる
  • 目標 matrix(metric × channel × month)と実績を結合した予算ペース警告を自動で出す仕組みが必要
「毎週のレポート作成をゼロにして、意思決定に時間を使う」

アプローチ

単一のダッシュボード基盤を構築し、クライアント別設定(GA4 Property / GSC URL / 媒体 / CV 定義 / 目標 matrix)で挙動を切り替える設計。Better Auth Multi-tenant で各クライアントは自分の slug のみアクセス可。API 自前取得+ Windsor.ai で媒体カバレッジを補完し、Claude による異常検知・サマリ生成を組み込み。

  1. 01

    Phase 1

    案件別設定の抽象化

    クライアント別設定(GA4 Property / GSC URL / Raw Sheet ID / Targets Sheet ID / 媒体リスト / CV 定義)を型付けされた設定オブジェクトに集約。新規案件は設定追加のみで基盤を共有する構成に。

  2. 02

    Phase 2

    データ統合レイヤー

    GA4 / GSC は SA + OAuth フォールバック、Google Ads は自前 API、Yahoo / Meta / Microsoft は Windsor.ai 経由で取得。ECCUBE / Shopify は Sheet or API 経由。全てを日次で正規化し Raw → Pivot → Join のパイプラインに集約。

  3. 03

    Phase 3

    Multi-tenant 認証 + 画面構成

    Better Auth + Neon Postgres で Organization / Member / Invitation を管理。クライアントは自分の slug のみアクセス可、admin は全体横串。複数画面(サマリー / 広告詳細 / フィルター詳細 / 商品・検索)+ 期間プリセット + 比較 + PDF 書き出し。

  4. 04

    Phase 4

    AI 異常検知・サマリ生成

    Claude で日次の数値変動を Z-score ベースで検知し、重要度付きのアラートを生成。月次サマリや定例レポートの初稿も LLM が生成し、人間は判断と意思決定に集中する構造に。

成果

共通基盤を複数案件に横展開した段階で、案件ごとに個別のレポート作成コストがほぼ消え、クライアントは自分の slug から日次最新データにアクセスできる構造が定着。定例会議の論点が「数値の確認」から「判断と次アクション」に明確にシフトし、基盤そのものが mixednuts の差別化資産として機能する状態に到達。

  • 01

    複数案件を単一基盤で運用できるようになり、新規案件の立ち上げが設定追加 + Sheet 共有のみで完了する状態に到達

  • 02

    日次自動更新で異常値検知が定例前に実施可能になり、対応のリードタイムを週次から日次に短縮

  • 03

    Multi-tenant 認証で他クライアントの存在を秘匿したまま同一基盤で運用する構造を確立

  • 04

    Claude による異常検知 + サマリ生成で、週次定例レポートの初稿作成工数をほぼゼロに

学び

  • ダッシュボードは「表示」より「設定の抽象化」が品質の決定要因。新規案件を型付き config だけで乗せられるか が拡張性を決める
  • Multi-tenant は UI 上の隠蔽だけでなく、認証・URL・データフェッチすべての層で分離することが必須
  • LLM の異常検知は閾値ベースより、統計的 Z-score + 事業文脈(目標 matrix)の組み合わせで精度が出る

応用できる領域

複数案件を並走運用するコンサルファーム・広告代理店・社内エージェンシー。特に計測環境が案件ごとに異なる局面で、共通基盤化による運用レバレッジを追求したい場合に応用可能。

役割・成果物

mixednuts 自社基盤の設計者兼実装責任者。案件別設定の抽象化、データ統合レイヤー実装、Multi-tenant 認証、AI 異常検知まで一気通貫で構築する立ち位置。複数案件への横展開も同時に推進。

  • 01

    案件別設定を型付けする共通 config スキーマと、新規案件投入フロー

  • 02

    GA4 / GSC / Google Ads / Yahoo / Meta / Microsoft / Shopify / ECCUBE の統合取得パイプライン

  • 03

    Better Auth Multi-tenant + Neon Postgres 認証基盤(Organization / Invitation フロー含む)

  • 04

    Claude ベースの異常検知 + 月次サマリ生成プロンプトと運用ルール

Discuss your case

同じ型を、
あなたの事業へ。

守秘義務の範囲内で、類似案件の進め方と適用可能性をご説明します。