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

チームの紹介

リーダーシップ

• Djordje Micovic, Senior Manager, Marketing Analytics

チームメンバー

各機能別マーケティングチームには、マーケティングアナリティクスチームの指定窓口があります：

チームのミッション

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

私たちの仕事は、ビジネスが知る必要があることと、現在見えていることのギャップを埋めることです。信頼性の高いデータインフラを構築することも重要ですが、それだけでなく、リーダーシップがリソースの配分方法、プログラムの評価方法、戦略の設定方法を変えるようなインサイトを積極的に提供することも重要です。

私たちは、維持しているダッシュボードの数や対応したリクエストの数ではなく、影響を与えた意思決定と、より良い成果に向けてより多くの費用を向けることを助けたことによって影響を測定します。

作業方法

私たちは広範な領域を支援する小さなチームです

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

小さなチームであるため、時間の使い方が重要です。厳しく優先順位を付け、必要なときには断り、毎四半期同じものを再構築しないよう一度しっかり作ることに投資します。

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

私たちは複数のタイムゾーンにまたがって作業しています。ほとんどのコラボレーションは、GitLab Issues、Slack、共有ドキュメントを通じて非同期で行われます。優先順位を調整し、ドメインをまたいでコンテキストを共有し、一人では答えられない大きな質問に取り組むために、チームミーティングで同期します。

即座の返信を期待するのではなく、Slack メッセージのスケジュール送信を活用します。意思決定は DM ではなく Issue に記録します。

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

各アナリストにはプライマリのドメインオーナーシップがあります。しかし、ドメインを壁として扱いません。最良のインサイトは、ファネル全体のデータを結び付けることから生まれます：Web サイトで何が起きているか、それがどのように MQL に流れ込み、セールスを通じてどのように転換し、最終的にどのような収益になるか。

自分のドメインで作業していて別のドメインに影響するものを発見したら、声を上げてください。通常のスコープ外のデータを探求したい場合は、マーケティングデータ以外でも、完全な許可があります。

AI 開発

私たちは、チームの GitLab リポジトリをすべてのコードの唯一の情報源として使用しながら、エージェント型ツールと AI スキルを協調的に開発します。原則はシンプルです：チームの誰かが役立つプロンプト、スキル、エージェントワークフローを構築した場合、それは個人のラップトップに留まるのではなく、全員が使用し、学び、改善できるようにリポジトリに入れます。

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

サポートの依頼方法

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 チャンネルに ping してください。優先順位を変更します。しかし「緊急」とは、「ステークホルダーがすぐに欲しい」ではなく、今日ビジネスに影響が出ていることを意味します。

チームの原則

これらは私たちがチームとして約束した行動規範です。理想的な企業の価値観ではなく、お互いに守り合う実践的な規範です。

1. 互いをサポートする

私たちはお互いの最初の連絡先であり、最後の手段ではありません。ステークホルダーとの会話で詰まっているとき、データモデルで苦労しているとき、優先順位付けに迷っているとき — チームに連絡してください。私たちは同じマネージャーを持つ個人の集まりではありません。一体として行動します。

実践的には：積極的にコンテキストを共有し、チームメンバーが過負荷になっているときに支援し、チームメンバーがチーム内で聞く前にステークホルダーから重要なことを知ることは絶対に避けてください。

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

リクエストが来たら、一歩立ち止まります。成果物を約束する前に、実際に何が求められているか、なぜそれが求められているかを理解します。何かを急いで構築したものの、誰も必要としていなかった、または本当の質問が述べられたものとは異なっていたことで、多くのサイクルを無駄にしてきました。

次のことを問いかけます：これはどのような意思決定に役立つか？私たちが見つけたものに基づいて何が変わるか？答えが不明確な場合は、作業を約束する前に明確化を求めます。

3. 自律的なマネージャーであれ

このチームの各メンバーは、自分の作業を自律的に管理することが信頼されています。優先事項を知っており、目標を知っており、入ってくるリクエストが緊急なのかノイズなのかを判断する方法を知っています。

チーム目標にあるか、マネージャーが明確にフラグを立てた場合 — それが優先事項です。そうでない場合は、断る、延期する、またはエスカレーションする権限があります。不確かなときは提起しますが、優先順位についての質問だけでなく、自分の推薦も持ってきてください。高いレベルで活動するには優先順位付けの判断力が必要であり、私たちはチームがその能力を持てるよう努力します。

4. 品質を量よりも重視する — 特に AI において

私たちは AI ツールを積極的に使用してより速く進みます。しかし、このチームから出るものはすべて人間がチェックしなければなりません。Issue、Slack メッセージ、成果物に AI 生成のスラップはありません。読んでいる人が機械が書いたものでレビューされていないとわかる場合、送信準備ができていません。

基準：答えが内容なく非常に長いか？正直に言って — 完全な答えか、それとも半端な AI 分析か？AI にやらせるのではなく、AI を活用してスキルセットを向上させることに努めてください。

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

数字が下がっていることを示すダッシュボードは運用レポートです。その下落の収益への影響を定量化し、具体的な行動方針を推奨する分析 — それが私たちが目指すものです。

私たちは、求められるのを待たないチームを目指しています。壊れているものを見つけ、調査し、ビジネスへの影響を明確にして、適切な人々の前に提示します。

私たちの作業

セルフサービスダッシュボードを公開して、チームが主要なマーケティング KPI を理解できるよう支援しています。ダッシュボードページには、サポートされているダッシュボードと新しいダッシュボードを公開するためのフレームワークが記載されています。

ダッシュボードは、マーケティングメトリクスページで定義されたメトリクスに基づいています。

サポートする内容

GitLab のエンタープライズデータウェアハウス（EDW）を使用して、ダッシュボードとレポートを構築します：

• 信頼できるデータ（SoT）Tableau ダッシュボード
• Snowflake と Tableau でのアドホックレポート
• Google スプレッドシートでのアドホック調査

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

以下のアプリケーションのビジネスオーナーです

• Bizible
• Allocadia
• Google Analytics
• Hightouch

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

重要なリソース

• マーケティングメトリクス
• ダッシュボードページ
• マーケティングアナリティクスデータ概要および一般情報

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