Amazonデータ分析の分析編：3軸フレームワークと要因分析の3段階

前編のAmazonデータ分析の環境構築編では、セラーセントラル・ベンダーセントラル・広告コンソール・AMCといった分散したデータソースから、どうデータを収集・保管・統合するか――分析の土台づくりについて解説しました。ASIN×日別の粒度、売上の2つの分解軸（ファネル分解・流入経路分解）、自社カテゴリー分類（出品者カテゴリー）といった「データをどう貯めるか」の設計まで整理したはずです。

しかし、データを貯めただけでは売上は伸びません。データは「分析して、施策に繋げて、その結果を検証する」ところまで到達してはじめて価値を生みます。「売上が落ちている気がするが原因がわからない」「月次レポートは毎回作っているが議論が深まらない」「施策を打ったがそれが効いたのか判断できない」――こうした状況に心当たりがある方は多いのではないでしょうか。

本記事では分析環境が構築されていることを前提に、「分析の設計と施策への落とし込み」に焦点を当てます。ポイントは大きく2つ。ひとつは分析を「モニタリング / 原因分析 / 施策の評価」の3軸で捉え直すこと。もうひとつは、分析の質を決める3つの重要観点――「数字は比較することに価値がある」「カテゴライズして分析する」「要因分析は3段階」――を全ての分析に通底させることです。なお、分析結果を誰にどう届けるか（ダッシュボード・定例レポート・アドホック分析）のアウトプット設計については、別記事で改めて扱います。

分析は「3軸」で捉え直す

Amazonに限らず、マーケティングのデータ分析はまず3つの軸に整理できます。目的・問い・使うデータ・アウトプットの形が異なるため、混同すると「何を見たいのかわからないレポート」が生まれます。まずはこの3軸を押さえることが、分析設計の出発点です。

重要なのは、これら3軸を独立した活動として切り分けるのではなく、サイクルとして連動させることです。モニタリングで変化を検知し、原因分析で要因を特定し、打ち手を実行したら施策評価でその効果を検証する。検証の結果がまた次のモニタリング・原因分析の前提になります。このサイクルが回ってはじめて、データ分析は意思決定に貢献します。

なお従来は「予測」や「施策設計」を独立した型として扱うこともありますが、実務ではこれらは3軸の文脈に自然に溶け込みます。予測はモニタリングの延長（着地見込みとして目標との差分を見る）、施策設計は原因分析と施策評価の接続点（なぜ起きたかを踏まえて次に何をやるか）として捉えれば十分です。まずは3軸をシンプルに回すことに集中しましょう。

全ての分析を貫く3つの観点

3軸の運用の質を決めるのが、以下の3つの観点です。モニタリングでも原因分析でも施策評価でも、この観点が抜けると分析は「数字を並べただけ」で終わります。

1. 数字は比較することに価値がある：単一の数字には意味がない。必ず比較の文脈で見る
2. カテゴライズして分析する：全体とASINの間にある「カテゴリー粒度」で切る
3. 要因分析は3段階：KPIに分解する → いつ変化したか特定する → なぜ変化したかを推測する

以降のセクションで、これら3観点を3軸にどう織り込むかを具体的に見ていきます。

軸1：モニタリング — 数字は比較して初めて意味を持つ

モニタリングの目的は「何が起きているか」を素早く把握し、異常を検知することです。日々の売上・広告・在庫・KPIの状況を継続的に観測し、意思決定者がほぼリアルタイムで状況を把握できる状態を作ります。

ここで最初に押さえるべきは、「単一の数字には意味がない」という原則です。「昨日の売上は500万円だった」という数字だけを見せられても、良いのか悪いのかは判断できません。数字は比較することで初めて評価可能な情報になります。

観点A：比較軸を必ず併記する

モニタリング指標には最低限、以下の比較軸を組み合わせて表示します。

特に実務で重要なのがYoYとMoMの使い分けです。AmazonはプライムデーやブラックフライデーなどのBig Eventに売上が大きく左右されるため、MoMだけを見ていると「プロモ明けで売上が落ちた」という当たり前の現象をわざわざ問題視してしまいます。こうした季節性はYoYで排除するのが鉄則です。一方でYoYだけでは「先月からの変化」が見えず、施策の反映確認や入札のチューニングには向きません。中長期の健全性はYoY、短期のチューニングはMoM/WoWと役割を分けましょう。

そしてもう一つ、見落とされがちな実務ポイントがあります。当月・今週といった期間途中の数字は、そのまま目標やYoY・MoMと比較してはいけないという原則です。たとえば「4月15日時点の当月売上が1,800万円」という数字を、先月の月間売上や目標3,500万円と並べても意味のある比較にはなりません。月の進捗途中の時点では、どれだけ積み上がっているかが単に時間経過の関数だからです。

期間途中の数字を正しく評価するには、まず着地見込みを算出してから、比較軸に当てはめるというひと手間を挟みます。

ダッシュボードで当月指標を並べる場合、実績値だけでなく着地見込みを必ず併記するのが実務上の最低ラインです。着地見込みなしに「目標3,500万円に対して現在1,800万円（達成率51%）」と見せても、月半ばで51%は良いのか悪いのか判断できません。「着地見込み3,300万円／達成率94%／目標対比-6%」まで揃えて初めて、意思決定につながる情報になります。

ダッシュボードを設計するときに「数字をたくさん載せたくなる」のは自然な誘惑ですが、重要なのは情報量ではなく「比較の文脈で異常が瞬時に分かるか」です。主要KPIそれぞれに目標対比・YoY・MoMを併記し、閾値を超えた指標は赤・黄で色分けする――この設計が最低ラインです。

観点B：カテゴリー単位で観測する

モニタリングでもうひとつ重要なのが「粒度の設計」です。モニタリングというと「全社売上」や「ブランド全体の広告費」のような俯瞰指標を思い浮かべがちですが、これだけでは異常を早期に捉えられません。逆にASIN単位で監視すると、数百〜数千ASINの小さな変動に埋もれて、本当に重要なシグナルを見失います。

実務で機能するのは、全体とASINの間にある「カテゴリー粒度」です。具体的には以下のような軸でカテゴライズします。

• 自社カテゴリー：商品ライン・ブランド・事業部。前編で触れた「出品者カテゴリー」がこれに該当します。Amazonカテゴリーではなく自社の経営粒度で切ることが肝心
• キャンペーン目的分類：獲得 / 認知 / 防御（自社名キーワード）。同じ広告費でも目的が違えば評価すべき指標が変わる
• 顧客区分：新規 / 既存 / リピーター。同じ売上500万円でも新規比率が高いか既存頼みかで次の打ち手がまったく違う
• 期間区分：プロモ期 / 通常期。セール売上と定価売上を混ぜたまま見るとブランド健全性の判断を誤る

モニタリングは「全体→カテゴリー→ASIN」のドリルダウン構造で設計するのが基本です。画面上部に全体サマリー、中段にカテゴリー別の一覧、気になる数字をクリックするとASIN別・日別に掘れる――この3階層があれば、異常の検知から原因の絞り込みまで数クリックで辿り着けます。

軸2：原因分析 — 3段階のフレームワーク

モニタリングで変化を捉えたら、次はその原因を突き止めるフェーズです。原因分析を場当たり的にやると「色んな数字を眺めて、それっぽい仮説を後付けする」ことになりがちです。これを構造化するのが要因分析の3段階フレームワークです。

この3段階の順序を守ることが肝心です。順番を飛ばして最初から「競合が値下げしたからでは？」と外部要因の推測に行くと、的外れな仮説に時間を浪費します。

STEP1：KPIに分解する

まず「どのKPIが動いたのか」を特定します。ここで活きるのが前編で定義した売上の2つの分解軸です。

分解軸1：ファネル分解

売上 = ページビュー（PV）× 注文率（CVR）× 注文単価

「売上が下がった」という漠然とした事実を、PV減なのか・CVR低下なのか・単価下落なのかに切り分けます。これだけで打ち手の方向性は大きく絞られます。

分解軸2：流入経路×広告KPI分解

総売上 = 自然売上 + 広告売上、広告売上 = 広告費 × ROAS、ROAS = CVR × CV単価 ÷ CPC

広告売上が落ちたなら、広告費を絞ったのか・ROASが劣化したのか。ROAS劣化ならCPC高騰か・CVR低下か。このように分解していけば、「広告売上が下がった」という事実から数ステップで具体的な打ち手候補まで辿り着きます。

ここでも観点B（カテゴライズ）が効きます。全ASIN合算でPV・CVR・単価を見ても「そこそこ変動している」という曖昧な結論しか出ません。自社カテゴリー単位で分解すれば、「ナッツ系はPV減が主因」「ギフトセットはCVR低下」のように原因がクリアに立ち上がります。

STEP2：いつ変化したのか特定する

動いたKPIを特定したら、次に「そのKPIがいつ変化したのか」を日別の時系列で見ます。変化点を特定せずに原因を推測するのは、事故の時間を知らずに事故原因を推理するようなものです。

変化のパターンによって、取るべきアクションはまったく異なります。

• 月初から徐々に落ちた：じわじわ進行する構造要因（競合の継続的な広告強化、カテゴリー市場の縮小、SEO劣化など）が疑わしい
• 特定の日に急落した：単発の事象（在庫切れ、商品ページ変更、広告停止、アルゴリズム変更など）がほぼ確定
• 特定期間だけ悪化している：期間連動の要因（競合のセール、自社プロモ明けの反動、季節性）を疑う

ここで前編で整理した「ASIN×日別の粒度で蓄積する」設計が決定的に効いてきます。月次合算しか見られない分析環境では、急落と緩降下の区別すらつきません。日次データがあるからこそ変化点を可視化でき、変化点があるからこそ次のSTEP3で仮説が絞れます。

STEP3：なぜ変化したかを推測する

変化点のタイミングが分かったら、その時期に起きた事象と突き合わせて原因を推測します。外部要因と内部要因を両方洗い出すのがポイントです。

仮説は検証可能な形に落とすことが重要です。「競合が値下げしたからでは？」で止まらず、「4月10日の時点で競合AのASIN XXXが〇〇円→△△円に値下げしている → 自社のCVRは4月10日以降に明確に低下 → この時間軸が一致するか」というレベルまで落とすと、仮説が検証可能になります。

通し事例：「売上が落ちた」の追い方

3段階フレームワークを具体例で追ってみます。前提は「ナッツ系カテゴリー（自社分類）の売上が先月比-12%」というモニタリング起点のアラートです。

1. STEP1（KPI分解）：ナッツ系のPV・CVR・単価を分解 → PVが-18%と大きく落ちている。CVR・単価はほぼ横ばい。続いて流入経路分解 → 広告経由PVが-25%、自然PVは-8%。広告経由の落ち込みが主因と判明
2. STEP2（変化点特定）：広告経由PVの日別推移を確認 → 4月5日以降に急落。緩降下ではなく明確な変化点がある。つまり単発の事象
3. STEP3（原因推測）：4月5日前後に起きた事象を洗い出す → 内部要因として「4月4日にSP主要キャンペーンの日予算を削減」が該当。広告運用ログで確認 → 日予算削減が原因とほぼ確定。打ち手は日予算を元に戻す、または予算配分を見直す

この流れは、ASIN×日別データと自社カテゴリー（ナッツ系）があって初めて辿れます。前編で整えた環境が、ここで初めて価値を発揮するわけです。

原因分析で使う主要な切り口

3段階フレームワークを支える主要な分析の切り口を一覧化しておきます。すべてをいきなり揃える必要はありませんが、原因分析の引き出しとして持っておくと便利です。

特にAMCを活用したNTB（ブランド新規）比率・N-CPA・LTV・リピート率は、ROASだけでは見えない示唆を与えてくれます。「短期ROASは悪いがNTB獲得単価が低くリピート率が高い」キャンペーンは、中長期では優れた投資です。AMCの活用方法はAMC入門：知っておきたい基本機能もご参照ください。

軸3：施策の評価 — やりっぱなしで終わらせない

原因が分かれば打ち手を実行します。しかし多くの現場で抜け落ちるのが「打った施策が本当に効いたのかを検証する」プロセスです。施策を打ちっぱなしにすると、次の打ち手が当たったのか外れたのかが分からず、学習が蓄積しません。

施策タイプで検証手段を使い分ける

施策評価の第一歩は、検証手段を施策タイプに合わせて選ぶことです。Amazonの施策は大きく2種類に分かれ、それぞれに適した検証手段が異なります。

商品ページ要素の変更は、Amazonが公式に提供する比較テストの管理（Manage Your Experiments）でユーザー単位のランダム割当によるA/Bテストが実施できます。ブランド登録済みかつ対象ASINに一定のトラフィックがあれば、Before/Afterでは原理的に排除できない外部要因まで構造的にキャンセルできるため、使える場面では必ず比較テストの管理を優先するのが合理的です。詳細はAmazonの「比較テストの管理」──A/Bテスト活用完全ガイドと対象外施策の検証フレームを参照してください。

一方、広告・プロモーション・価格・外部誘導などページ外で動く施策はA/Bテストになじまないため、Before/After比較で時系列評価するのが現実解です。以降は、このBefore/After評価を質高く回すためのポイントを整理します。

Before/After比較：比較は評価の基本

施策評価でも観点A（数字は比較することに価値がある）が効きます。「施策実行後にROASが3.5になった」では評価できません。必要なのは以下のような比較です。

• Before/After比較：施策実行前の同期間と比較する（例：直前4週間の平均 vs 実行後4週間）
• テストグループ vs コントロールグループ：一部のカテゴリー・キャンペーンだけに施策を適用し、適用外と比較する。季節性や外部要因を相殺できる
• YoY比較：プロモ期の施策など季節性の影響を受ける場合は、前年同期の同条件と比較する

Before/Afterだけを見て「ROASが改善した」と判断すると、単に季節要因や競合のセール終了で改善しただけ、というケースを拾い損ねます。施策評価には必ず「もし施策を打たなかったら」の比較対象を用意する発想を持ちましょう。

評価期間の設計：短すぎず、長すぎず

評価期間の設計も侮れません。短すぎると数日のノイズで判断してしまい、長すぎると次の打ち手が遅れます。施策タイプ別の目安は以下です。

Before/After期間は「クリーンな期間」を意図的に選ぶ

Before/After比較のクオリティを決めるのは、期間の「長さ」以上に期間の「選び方」です。Amazonは年間を通じてどこかで大型セールやプロモが動いているため、雑に前後4週間を切り出すと、施策の効果と外部イベントの効果が不可分に混ざってしまいます。期間選定時は以下を必ずチェックします。

• 大型セール・プロモを跨がない・含まない：プライムデー・ブラックフライデー・サイバーマンデー・初売りなどをBefore／After期間に入れない。どうしても跨ぐ場合は前年同期のセール期間同士で別軸比較する
• 他施策の変動と重ねない：評価したい施策以外の変数（別キャンペーンの予算倍増、同時期のクーポン発行など）がBefore／After期間に動いていないか確認。検証したい1施策以外はなるべく動かさないクリーンな期間を確保する
• 在庫切れ・サスペンド期間を避ける：売上ゼロ／極端に低い日が入ると成長率計算が崩れる。販売状態が安定している期間を選ぶ

「Before28日／After28日」のような機械的ルールをそのまま当てはめるのではなく、案件ごと・施策ごとにカレンダーを見ながら個別判断することが、Before/After検証の精度を左右します。ページ外施策の具体的なBefore/After検証フレームは比較テストの管理とBefore/After検証フレームで5ステップ（事前設計→期間定義→KPI設計→実行と記録→レポート作成）として整理しているので、あわせてご覧ください。

評価→学習→次の施策のループ

施策評価の最終目的は「効いたかどうかの判定」ではなく「次の施策に学習を蓄積すること」です。運用を成熟させる企業は、以下のようなループを制度化しています。

1. 施策を打つ前に仮説・期待効果・評価指標・評価期間を明文化する
2. 評価期間が終わったら、実績と期待効果を比較する（Before/After + コントロール群）
3. 想定通りか・外れたか、外れた場合は「なぜ外れたか」まで踏み込む（原因分析の3段階を再度適用）
4. 得られた学習を次の施策候補リストに反映する

定例MTGの議題構成も、「今週の数字はこうでした」で終わる会議ではなく、「先々週に打った施策の評価結果 → 次に何をやるか → 誰が担当するか → いつ振り返るか」まで決まる会議に変えましょう。分析結果が意思決定につながる組織は、例外なくこのループが回っています。

分析運用でよくある落とし穴

分析のフェーズは、環境構築以上に「運用の巧拙」で差が出る領域です。多くの現場で見られる落とし穴を整理します。

1. 比較軸なしの数字を見せる

「今月の売上は3,200万円です」のように単一の数字を並べただけのレポート。読み手は良いのか悪いのか判断できません。目標比・YoY・MoMのいずれかを必ず併記するのが最低ライン。観点Aが守れていない典型例です。

2. 粒度が「全体」か「ASIN」しかない

全社売上の全体合計と、ASIN単位の細かいデータは揃っているのに、その間の「自社カテゴリー」がない。結果、経営会議では抽象的な議論、現場では細かすぎて示唆が埋もれる、という両極端になります。観点Bが守れていない典型例。全体→カテゴリー→ASINの3階層を常に意識しましょう。

3. 分析が「やった感」で終わり施策に繋がらない

分析レポートを作った時点で満足し、施策実行まで繋がらないケース。「分析→議論→意思決定→実行→評価」のサイクルが制度化されていないことが原因です。定例MTGを「分析発表」ではなく「意思決定」の場に変えることが対策になります。

4. 施策を打ちっぱなしで評価しない

施策を打つときは盛り上がるのに、その後の効果検証が形式的になる――よくある光景です。施策を打つ前に評価指標・評価期間・比較対象を決めておかないと、事後の検証は主観的な感想で終わります。軸3をサイクルに組み込みましょう。

5. 数値だけ見て定性情報を無視する

競合の新商品投入、Amazonアルゴリズム変更、SNSでの話題化――こうした定性情報は数字に遅れて現れます。優れたマーケターは数字の変化に対して「なぜそう変化したか」の定性仮説を常に並行させています。原因分析のSTEP3（外部要因・内部要因）を仕組み化することで、数字と定性のバランスを保てます。

Ubun BASEで実現する分析の仕組み

前編で紹介した通り、Ubun BASEはセラー・ベンダー両対応でデータ収集・保管・統合の環境構築をワンストップで提供します。本記事で整理した3軸（モニタリング / 原因分析 / 施策の評価）と3観点（比較 / カテゴライズ / 3段階要因分析）を、ホーム画面・マンスリーレポート・施策レポートという3つの画面に落とし込んでいます。

分析の前提設定：出品者カテゴリーと売上目標

後述する各画面の分析精度を決めるのが、初期設定の出品者カテゴリーと売上目標です。この2つを整えることで、観点B（カテゴライズ）と観点A（比較＝目標対比）が仕組みとして常に効いている状態を作れます。

出品者カテゴリーは、Amazon側のカテゴリーとは別に自社独自の分類軸でASINをグルーピングする機能です。商品ライン・ブランド・事業部など、自社の経営や現場の意思決定で使っている粒度で設定できるため、前編で触れた「Amazonカテゴリーは自社の分析粒度と一致しない」という課題をそのまま解消します。一度設定すれば、ホーム画面・各種レポート・マンスリーレポート・施策レポートのすべてが出品者カテゴリー軸で自動集計されるので、「ナッツ系」「ギフトセット」など社内で普段使う言葉でそのまま分析・議論できる状態になります。

売上目標は、全社・カテゴリー別・月別に設定できます。設定した目標はホーム画面の着地見込みと自動で突き合わされ、着地見込み／目標対比／達成率がカテゴリー単位でリアルタイムに可視化されます。目標のないダッシュボードは「数字の羅列」で終わりますが、目標と着地見込みを常に並べて見ることで、月の早い段階から「どのカテゴリーに追加のテコ入れが必要か」という意思決定につながります。

ホーム画面：モニタリングから原因分析まで一気通貫

ホーム画面では、任意のカテゴリー単位で当月の着地見込み・YoY・MoMがひと目で分かります。観点Aで述べた「期間途中の数字は着地見込みを出してから比較する」という原則と、観点Bの「カテゴリー粒度で見る」を同じ画面で同時に満たせる設計です。当月の進捗を実績値だけで判断するのではなく、月末にどこへ着地しそうかを目標・YoY・MoMと並べて即座に判断できます。

気になるカテゴリーをクリックすれば、KPI分解（PV・CVR・単価、CPC・CVR・CV単価など）、日別・月別のトレンド分析、ASINハイライトまで一気通貫で掘り下げられます。つまり、本記事で整理した軸1（モニタリング）から軸2（原因分析）への遷移が、画面設計としてそのまま組み込まれているということです。要因分析の3段階（KPI分解→変化点特定→原因推測）のうちSTEP1とSTEP2をクリックだけで辿れる状態になっています。

マンスリーレポート：網羅的に状況を俯瞰し、有意な変化に気づく

月次の振り返りにはマンスリーレポートを用意しています。売上・広告・顧客指標などを網羅的に確認でき、どのカテゴリー・どのKPIで有意な数字の変化が起きているかを短時間で把握できます。ホーム画面が「日々のモニタリング」を担うのに対し、マンスリーレポートは「月単位の棚卸し」を担うポジションです。

加えて、ホーム画面とマンスリーレポートにはAIサマリーが組み込まれており、売上・広告の変動に対して重要な変化点と推測される要因を自動でコメントします。自分でダッシュボードを眺めて変化を探すのではなく、AIが先に「ここを見てください」と示してくれるため、変化の見落としを減らし、原因分析への初動を早くできます。

スライドレポートの施策レポート：Before/Afterを簡単に作れる

軸3（施策の評価）については、スライドレポート内の施策レポートでBefore/After比較レポートを簡単に作成できます。施策を打つ前に施策名・対象ASIN・反映日・比較期間・観察KPIを登録しておくと、検証期間が来たタイミングで前後比較レポートが自動生成され、メールで共有されます。本記事で強調した「評価指標と評価期間を施策前に決めておく」「施策を打ちっぱなしにしない」という原則を、ワークフローに組み込む形で実装しています。

なお、商品ページ要素の磨き込みについては、Amazon公式の比較テストの管理（Manage Your Experiments）を併用するのが合理的です。A/Bテストが使える領域はMYE、使えないページ外施策はUbun BASEの施策レポート――という使い分けで、運用全施策を評価可能な状態に保てます。

AMC分析と施策接続：中長期指標と運用への反映

短期ROASだけでは見えない中長期の健全性は、AMCレポートで追えます。リピート・ARPU・RFM・NTB比率・N-CPA・ブランドリーチ／フリクエンシー・セグメント別発注率などをSQLを書かずに定期実行でき、時系列で蓄積されるため施策前後の検証（軸3）にも流用可能です。

分析結果は自動入札とAMCオーディエンス配信で運用に接続できます。ポートフォリオ単位での予算・入札制御に加え、RFM等から作成したオーディエンスはSP/SB/SDキャンペーンへそのまま配信連携可能。「分析→施策」のリードタイムを短縮することで、3軸のサイクルが速く回る状態を作れます。

まとめ

分析環境を整えた後に問われるのは、「その環境をどう使って、どう施策に繋げるか」です。本記事の要点を振り返ります。

• 分析は3軸で捉える：モニタリング（何が起きているか）、原因分析（なぜ起きたか）、施策の評価（打った施策は効いたか）をサイクルで回す
• 観点A：数字は比較することに価値がある：単一の数字には意味がない。目標対比・YoY・MoM・期間比較を使い分ける。当月・今週など期間途中は着地見込みを出してから比較する。中長期の健全性はYoY、短期のチューニングはMoM/WoW
• 観点B：カテゴライズして分析する：全体とASINの間にある自社カテゴリー粒度で切る。全体→カテゴリー→ASINの3階層ドリルダウンが基本
• 観点C：要因分析は3段階：STEP1「KPIに分解する」→ STEP2「いつ変化したのか特定する」→ STEP3「なぜ変化したかを推測する」。順序を飛ばさない
• 施策評価は施策タイプで使い分ける：商品ページ要素は比較テストの管理でA/Bテスト、ページ外施策はBefore/After比較。期間は「長さ」より「クリーンさ」が重要
• 施策はやりっぱなしで終わらせない：評価指標・評価期間・比較対象を事前に決め、学習を次の施策リストに蓄積する
• 分析と施策を仕組みで繋げる：人手の介在が多いほどサイクルは遅くなる。自動入札やオーディエンス配信連携など、分析結果が自動で施策に反映される仕組みが差別化になる

Amazonマーケティングの成熟度は、「どれだけデータを持っているか」ではなく「データから意思決定・施策までのサイクルをどれだけ速く、正確に回せるか」で決まります。Ubun BASEは、前編Amazonデータ分析の環境構築編で取り上げたデータ収集・保管・統合の基盤と、本記事で整理した3軸・3観点を一つのプラットフォームで支える設計です。分析を意思決定と施策に繋げる仕組みづくりの一手として、導入をご検討いただければ幸いです。

田中 友章

株式会社ウブン　PdM of UbunBASE

2007年に株式会社オプトに入社し、金融業界向けインターネット広告の提案・運用を担当。株式会社電通に出向し、大手ナショナルクライアントのデジタルメディア戦略の立案と実行に従事。2012年にオプトに帰任後、DSPや広告効果測定ツールのプロダクトマネージャーを歴任。グループ会社のスキルアップビデオテクノロジーズでは取締役として動画広告のアドテクノロジー事業を推進。2020年に株式会社ウブンに参画し、Amazonレポートの自動化ツール「Ubun BASE」を立ち上げ、開発とマーケティングを統括。