マーケティングアナリティクス

チームの紹介

リーダーシップ

• Djordje Micovic, Senior Manager, Marketing Analytics

チームメンバー

各機能別マーケティングチームには、マーケティングアナリティクスチームメンバーとの指定された連絡窓口があります:

チームミッション

私たちは GitLab のマーケティング組織がより良い意思決定を行えるよう支援するために存在します。何が起きたかを単に報告するのではなく、なぜそれが起きたのか、そしてそれに対して何をすべきかを説明します。

私たちの仕事は、ビジネスが知る必要があることと、現在見えていることの間のギャップを埋めることです。それは、信頼できるデータインフラストラクチャを構築することを意味しますが、同時に、リーダーシップがリソースを配分し、プログラムを評価し、戦略を設定する方法を変えるインサイトを能動的に表面化することも意味します。

私たちは、維持するダッシュボードの数や対応したリクエストの量ではなく、私たちが影響を与える意思決定と、より良い結果へリダイレクトするのを助けたドルで自分たちのインパクトを測ります。

私たちの働き方

私たちは大きな対象範囲を支える小さなチームです

私たちはデマンドジェネレーション、Web アナリティクス、セールスデベロップメント、プロダクトレッドグロース、ブランド、イベント、デベロッパーリレーションズなどにわたるマーケティング機能を支える小さなチームです。Snowflake/dbt/Tableau/Salesforce のスタック上で運用しており、Marketo、Bizible、GA4 と深く統合されています。

私たちは小規模なため、時間の使い方が重要です。私たちは容赦なく優先順位を付け、必要なときには押し戻し、四半期ごとに作り直さないよう一度きっちり構築することに投資します。

非同期ファースト、意図的な同期

私たちは複数のタイムゾーンをまたいで働いています。コラボレーションの大半は GitLab Issue、Slack、共有ドキュメントを通じて非同期に行われます。優先事項を揃え、ドメイン間でコンテキストを共有し、一人では答えられない大きな問いに取り組むために、チームミーティングで同期します。

即時の応答を期待するのではなく、Slack メッセージをスケジュール送信します。DM ではなく Issue に意思決定を文書化します。

ドメインのオーナーシップ、共有された好奇心

各アナリストには主担当ドメインがあります。しかし、私たちはドメインを壁として扱いません。最良のインサイトはファネルを横断したデータの接続から生まれます。ウェブサイトで何が起きているか、それが MQL にどう流れ込み、セールスを通じてどう変換され、最終的にどれだけの収益が出るかなどです。

自分のドメイン内で作業中に他のドメインに影響することに気づいたら、声を上げてください。普段のスコープを越えてデータを探索したい場合は、たとえそれがマーケティングデータの外であっても、十分に許可されています。

AI 開発

私たちはエージェント型ツールや AI スキルを協調的に開発しており、チームの GitLab リポジトリをすべてのコードの単一の真実の情報源として使います。原則はシンプルです: チームの誰かが有用なプロンプト、スキル、エージェントワークフローを構築したら、それは個人のノートパソコンではなく、誰もが使い学び改善できるよう、リポジトリに格納されます。

私たちはこれらのスキルを一緒にイテレートし、リポジトリへの追加・変更には必ずマージ前にピアレビューが必要です。これにより品質を高く保ち、知識をチーム全体に広め、個人のショートカットではなく共有された能力を構築していることを保証します。私たちはベースラインとしてエージェント型ツール開発のデータチーム標準に従い、チームのユースケースが要求する場合はそれを拡張します。

私たちに助けを求める方法

GitLab Issue から始めてください

すべてのリクエストは GitLab Issue として提出してください。 これは交渉の余地はありません。なぜなら Slack スレッドは消え、コンテキストは失われ、見えないものは優先順位付けできないからです。

誰もが私たちのチームに Issue を作成する権限を持っています。助けが必要な場合は、私たちが正しい形にするのを手伝います。よく書かれた Issue はより早く解決されます。私たちはキャパシティとドメインに基づき、定期的に Issue をレビューしてチームメンバーに割り当てます。未割り当ての Issue は、独自のトリアージボットを通じて週次でアラートをトリガーします。

シニアリーダーシップ (VP+) からのリクエストでライブのコンテキストと要件を提供いただける場合などのまれなケースでのみ、短い会話や Slack スレッドに基づいて私たちが代わりに Issue を作成します。

完了したチームの作業はすべて、関連する GitLab Issue を持つよう努めています。

良いリクエストの要件

私たちが迅速に対応できるリクエストには以下が含まれます:

• 答えようとしている問い - 「ダッシュボードが必要」ではなく、「X がうまく機能しているかを理解して、Y を判断したい」
• この情報がどんな意思決定に役立つか - これを明確に表現できないなら、リクエストはまだ準備が整っていない可能性が高いです
• このリクエストが支えるカンパニーオブジェクティブ - リーダーがこの作業を支える共通の目標を提示できなければ、優先順位は付けられません。
• 関連するコンテキスト - キャンペーン、UTM パラメータ、アセットリスト、期間、オーディエンスセグメントへのリンク。提供されるほど、やり取りが少なくて済みます
• タイムライン - いつまでに必要か、その日程の根拠は何か?

優先順位付け

私たちの優先度スタック

私たちはすべての作業をシンプルな階層に照らして評価します:

1. チームオブジェクティブ - 四半期に向けて提供することをコミットしたもので、カンパニーレベルの目標に揃っています。常にこれが第一です。
2. リーダーシップが指定した優先事項 - オブジェクティブに含まれていなくても、シニアリーダーシップが明示的にクリティカルだと識別した作業。通常、エグゼクティブからのリクエストか、時間的制約のあるビジネスニーズに紐づいています。
3. チームオブジェクティブに沿ったステークホルダーリクエスト - すでにコミットしているものをサポートするリクエストは、自然に優先されます。
4. アドホックなリクエスト - それ以外すべて。対応はしますが、1〜3 を犠牲にしてまではしません。

私たちの「ノー」の伝え方

リクエストが現在のオブジェクティブと合致せず、優先事項としてもフラグが立っていない場合、私たちは敬意を持って、率直にそう伝えます。何に取り組んでいるか、あなたのリクエストを引き受けるために何の優先順位を下げる必要があるかを説明し、可能な代替案を提示します。

これは個人的なことではありません。「ノー」と言うことは、ビジネスにとって最も重要なものを提供する私たちの能力を守る方法です。

私たちの優先順位付けに同意できない場合は、マネージャーの Djordje Micovic にエスカレーションし、なぜリクエストを優先付けし直すべきかの根拠を示してください。

本当に緊急な場合

本物の緊急性は存在します - データインシデント、経営会議前にダッシュボードが壊れた、土壇場の取締役会向けリクエストなど。そのときは #mktg-analytics チャンネルで連絡してください。私たちは優先順位を付け替えます。ただし、「緊急」とはビジネスへの影響が「今日」発生していることを意味し、「ステークホルダーがそろそろ欲しいと言っている」ではありません。

チームの原則

これらはチームとして合意した運用上の取り決めです。理想的なコーポレートバリューではなく、お互いに守る実用的な規範です。

1. お互いの背中を守る

私たちはお互いの最初の連絡先であり、最後の手段ではありません。ステークホルダーとの会話で行き詰まったり、データモデルに苦戦したり、優先順位付けに迷ったら、悩む前にチームに声をかけてください。私たちは、たまたまマネージャーを共有しているだけの個人の集まりではありません。一つのユニットとして運用します。

実務的には: コンテキストを能動的に共有し、チームメイトが過負荷のときには介入し、チームメンバーが大事なことをチーム内ではなくステークホルダーから先に知ることのないようにする、ということです。

2. ソリューション設計の前にディスカバリー

リクエストが届いたら、一呼吸置いてください。デリバラブルにコミットする前に、実際に何が求められているのか、なぜそれが求められているのかを理解してください。私たちは、誰も必要としていないものを高速に作ったり、明示された問いと実際の問いが違ったりしたために、あまりに多くのサイクルを無駄にしてきました。

問いかけてください: この情報はどんな意思決定に役立つか? 見つかったことに基づいて何が変わるか? 答えが不明瞭なら、作業にコミットする前に明確化を求めてください。

3. 一人のマネージャーであれ

このチームの各メンバーは、自分の仕事を自分で管理すると信頼されています。あなたは自分の優先事項を知り、私たちのオブジェクティブを知り、入ってきたリクエストが緊急かノイズかを判断できます。

それがチームオブジェクティブ上にあるか、マネージャーが明示的にフラグを立てたなら - それは優先事項です。そうでないなら、ノーと言ったり、先送りしたり、エスカレートしたりする権限があります。迷ったら、ぜひ声を上げてください。ただし、優先順位付けの問いだけでなく、自分の推奨も持ち込んでください。ハイレベルでの運用には優先順位付けの判断力が必要であり、私たちのチームはそれができるようになることを目指しています。

4. 量より質 - 特に AI では

私たちは速く動くために AI ツールを積極的に活用します。しかし、このチームから出ていくものはすべて、人間が校正しなければなりません。Issue、Slack メッセージ、デリバラブルに AI 生成のスロップは厳禁です。読み手が「機械が書いて誰もレビューしていない」と分かるなら、送る準備ができていません。

基準: 答えは内容のないままただ長くはないか? 正直に言って、それは完全な答えか、それとも中途半端な AI 分析か? AI を使って自分のスキルセットを向上させるよう努めてください。AI に作業をさせるためではありません。

5. 意思決定を変えるインサイト

数字が下がっていることを示すダッシュボードはオペレーショナルなレポーティングです。その下落の収益インパクトを定量化し、具体的なアクションを推奨する分析、それが私たちがここにいる理由です。

私たちは、依頼されるのを待たないチームを目指して構築しています。何かが壊れていることに気づき、調査し、ビジネスインパクトを定式化し、適切な人々の前に置きます。

私たちの仕事

私たちはチームが主要なマーケティング KPI を理解するのに役立つセルフサービスのダッシュボードを公開しています。私たちのダッシュボードページには、サポートしているダッシュボードと新しいダッシュボードを公開するためのフレームワークが一覧されています。

私たちのダッシュボードは、Marketing Metrics ページで定義されたメトリクスに基づいています。

サポートする内容

私たちは GitLab の Enterprise Data Warehouse (EDW) を使って、以下を含むダッシュボードとレポートを構築します:

• Source of Truth (SoT) Tableau ダッシュボード
• Snowflake および Tableau でのアドホックレポート
• Google Sheets でのアドホック調査

Salesforce 内の SoT またはキャンペーンベースのダッシュボードはサポートしていません。

私たちがビジネスオーナーであるアプリケーション

• Bizible
• Allocadia
• Google Analytics
• Hightouch

アクセスをリクエストするには、ビジネスオペレーションのハンドブックに記載されているアクセスリクエストプロセスに従ってください。これらのツールへのアクセスを必要とする契約者やコンサルタントと作業している場合は、調達ハンドブックに記載されているプロフェッショナルサービスのアクセスリクエストプロセスに従ってください。

重要なリソース

• Marketing Metrics
• Dashboards Page
• Marketing Analytics Data Overview and General Information

ページのソースコードを見る - ページの編集 - please contribute.