一般に、マーケティングチームがアトリビューション数値に苛立ってご相談に来るとき、彼らは同じページの 2 つのチャートが食い違うダッシュボードを見せます。Paid Search が一方のカードで Top Source、別のカードで 3 番目の Source。チームは午前中、どちらのチャートが正しいか議論しています。チャートは問題ではありません。両方のチャートにフィードする単一の Lead Source プロパティが問題で、レポートレベルでいじくっても直りません。直し方は 1 層下、Contact レコード上のプロパティアーキテクチャに住みます。
なぜ今これが重要なのか
B2B バイヤージャーニーは長くノイジーになり続けています。ペイドタッチがオーガニックの上に積み重なり、Chat がフォーム入力と重なり、単一の Contact が SDR が拾う前にダースのインタラクションを蓄積します。Last-Click アトリビューションは簡単な答えでしたが、Last-Click は Harvard Business Review がマーケティング指標が合わない理由についての記事で述べたとおり、「今日の複雑なマーケティング努力の組み合わせが購買結果にどう影響するかを誤って表現します」。(hbr.org) 本能はレポートを直すことです。実際の直し方は、1 つのプロパティに 3 つの異なる問いの重みを運ばせるのをやめることです。
なぜ単一 Lead Source プロパティは常に負けるか
単一 Lead Source プロパティは毎日、少なくとも 3 つの異なる問いに答えるよう求められます。どのチャネルがこの Contact を私たちに紹介したか、どのチャネルが今日のアクティビティの前に最後にタッチしたか、彼らが手を上げた瞬間にどのチャネルがアクティブだったか。それらは 3 つの仕事です。1 つのプロパティは一度に 1 つの値しか持てないので、結局、最も最近のレースコンディションに勝ったシグナル、通常は最後のフォーム入力や最後のペイドクリックがそこにあったものを上書き、を保持します。
たとえば、Contact がオーガニックブログ投稿を通じてあなたを発見し、2 週間後にペイドソーシャル広告経由で戻り、最終的にウェビナーフォームでコンバートします。単一 Lead Source プロパティは「ウェビナー」、または最後にどのワークフローが発火したかによって「ペイドソーシャル」を読みます。コンテンツチームはブログが死んでいると思います。ペイドチームはクレジットを取ります。どちらのチームも正しくありません。プロパティが全ストーリーを語る余地を持たなかったからです。
First-Touch、Last-Touch、Converting-Touch：3 つのプロパティ、3 つの仕事
直し方は、Lead Source を 1 つのプロパティとして扱うのをやめ、3 つとして扱い始めることです。それぞれが明確に定義された仕事、明確に定義された書き込みルール、明確に定義された消費者を持ちます。
First-Touch、ライト・ワンス、Contact 作成時に設定
First-Touch プロパティは、どのチャネルがこの Contact を私たちに紹介したかに答えます。Contact レコードが作成された瞬間に設定され、決して上書きされません、ワークフローによっても、連携によっても、フォームによっても。書き込みルールはハードです：作成時にのみ設定可能、その後ロック。これがコンテンツと SEO チームが見るべきフィールドで、Contact のフルライフサイクルを、ペイドや終端アクティビティが歴史を書き換えることなく生き残る唯一のものだからです。
Last-Touch、最後の非ダイレクトインタラクション、更新可能
Last-Touch プロパティは、Contact が今していることの前に、どのチャネルが最後にこの Contact をタッチしたかに答えます。非ダイレクトインタラクションが着地するたびに更新します、ペイドクリック、Campaign タグ、Referral。Direct トラフィックは上書きしません（さもなくば入力された URL ごとに実際のマーケティングシグナルが消されます）。これがペイドチームが見るべきフィールドで、サイクル後半でも予算が仕事をしているかを反映するからです。
Converting-Touch、コンバージョン瞬間にロック
Converting-Touch プロパティは、この Contact が実際にコンバート、デモフォーム送信、MQL ヒット、手を挙げる、したまさにその瞬間に、どのチャネルがアクティブだったかに答えます。コンバージョンイベント時に設定され、First-Touch と同様に、その後決して上書きされません。これがセールスハンドオフと SDR ルーティングが見るべきフィールドで、認知のチャネルや最後の Campaign 露出のチャネルではなく、インテントのチャネルを捕捉するからです。
書き込みルール：各システムがどのプロパティを触れるか
3 つのプロパティは、書き込みルールがフォーム、ワークフロー、連携同期にまたがって厳密に強制される場合にのみ機能します。フォームは作成時に First-Touch、送信時に Converting-Touch を設定します、以上、Last-Touch には決して書き込みません。ワークフローは Campaign アトリビューションルールが発火したとき Last-Touch を更新しますが、設定後の First-Touch や Converting-Touch に触れることは禁じられます。ネイティブ広告連携と Reverse-ETL フィードは Last-Touch のみへの書き込みアクセスを得ます。プロパティの書き込み表面が制約されないなら、アーキテクチャは 1 四半期内に 1 プロパティの混乱に戻ります。
実務上の詳細：First-Touch と Converting-Touch フィールドは、フィールドが空かをチェックしてから書き込むワークフローでの「set once」ロジックでロックします。プラットフォームはネイティブにライト・ワンスを強制しないため、ディシプリンはワークフロー層に住みます。これは塩を一粒含めて受け取る必要があります、誰かが CSV をインポートするときは特に、強制は完璧ではありません、が、ワークフローが一貫して命名され四半期ごとにレビューされれば、パターンは持ちこたえます。
レポート層：レポートごとに 1 プロパティを選び、決して平均しないでください
3 つのプロパティは、それらにまたがって平均する 1 つのレポートではなく、3 つのレポートを意味します。コンテンツアトリビューションダッシュボードは First-Touch のみを読みます。ペイド効率ダッシュボードは Last-Touch のみを読みます。MQL-to-SQL ハンドオフダッシュボードは Converting-Touch のみを読みます。各レポートはタイトルとチャートサブタイトルでフィールドを命名し、それを歩み寄る誰もがどの問いに答えているかを理解します。3 つのフィールドをドロップダウンで切り替える単一の「Lead Source」レポートを構築する誘惑はリアルで、抵抗すべきです。ドロップダウンを使うすべてのチームは、現在どれが選択されているかを忘れて結果について議論します。
フラグすべき兄弟問題が 1 つ：Contact が既知になると、後続セッションでの UTM はデフォルトトラッキングで捕捉されなくなります、この投稿が扱うのとは別の失敗モードです。ここのプロパティアーキテクチャは入力がクリーンであることを前提とします。UTM ステッチングが上流で壊れていれば、3 プロパティモデルは 3 種類の悪いデータを忠実に記録します。
現場で見たパターン
後期シリーズ A の DACH の B2B SaaS マーケティングチームから、まさにこのダッシュボード矛盾でご相談がありました。彼らの単一「Original Source」フィールドは、再エンゲージした Contact が広告をクリックするたびにペイドソーシャルワークフローによって上書きされていました、そのため、コンテンツチームの月次レポートは、もともとブログからソースされた Contact が数か月後にペイドに再帰属されるにつれて崩壊し続けました。CFO は妥当に、なぜコンテンツ予算が存在するか尋ねました。プロパティを 2 週間のビルドで 3 つに分割しました。履歴のレコード作成スナップショットからバックフィルされた新フィールドとしての First-Touch、書き込みルールが狭められた既存ペイドワークフローに配線された Last-Touch、フォーム送信時に設定されロックされた Converting-Touch。1 か月以内にコンテンツチームの貢献が消えるのは止まり、ペイドチームは予算が実際に Contact を再エンゲージした場所での Last-Touch クレジットを保ち、セールスハンドオフはルーティングする安定したインテントチャネルを得ました。3 つの数字のいずれもあまり動きませんでした。同じアクティビティが、ようやく分離されただけです。
解決策：3 プロパティモデルを導入するためのプレイブック
- 既存の Lead Source プロパティを監査してください。それに書き込むすべてのワークフロー、連携、フォームをリストアップします。レースコンディションを探しています、2 つのシステムが互いを上書きしている場所。このリストは通常チームを驚かせます。
- 3 つの新プロパティを作成してください。1 つの First-Touch チャネルフィールド、1 つの Last-Touch チャネルフィールド、1 つの Converting-Touch チャネルフィールド。最初のパスで既存の Lead Source フィールドを再用途化しないでください、履歴レポートが機能し続けるよう、所定の場所に残します。
- ピックリスト値を 1 度定義し、3 つすべてで共有してください。同じ値、同じ大文字小文字、同じ順序。一方が「paid social」、別方が「paid - social」を持つ瞬間にレポートは崩壊します。
- 書き込みルールを配線してください。フォームは送信時に First-Touch（空のときのみ）と Converting-Touch を設定します。ペイド連携は Last-Touch のみに書き込みます。これらのフィールドに触れるすべてのワークフローは、所有するプロパティを示す名前プレフィックスを得ます。
- レコード作成タイムスタンプから First-Touch をバックフィルしてください。既存 Contact について、プラットフォームがすでに保持する Original-Source データを生き残るところで使用し、残りについては既知の未知を受け入れます。カットオフ日をドキュメント化します。
- 新フィールドに対してレポートを再構築してください。プロパティごとに 1 レポート。各々をプロパティ名でタイトル付け。古い単一ソースレポートはリタイアするか、誰も信用しないよう非推奨マークを付けます。
- 四半期ごとにワークフローインベントリをレビューしてください。誰かがレビューを所有する場合にのみアーキテクチャはクリーンに留まります。マーケティング Ops の常設アジェンダに追加します。
Checkpoint がどう関わるか
プロパティアーキテクチャは、誰もが実際に信用するすべての HubSpot ダッシュボードの背後にある華やかさのない仕事です。それが Checkpoint でマーケティングオペレーションサイドで行うことのほとんどです。Lead Source ダッシュボードが自分自身に矛盾しているなら、あるいはコンテンツ、ペイド、セールスが「Source」の意味について同意するのをやめたなら、直し方はほぼ常にダッシュボードの 1 層下にあります。次の四半期レビューがどのチャートが正しいかについての議論を再び強制する前に、ご相談ください。
出典
- Lindsay. 「Why Your Marketing Metrics Don't Add Up.」 Harvard Business Review、2014 年 9 月 9 日。hbr.org
- Hossain. 「A Simple Framework for Unlocking Full-Funnel Marketing Attribution Intelligence.」 OpenView Labs。openviewpartners.com
Noah Charak