Inbound Marketing ハンドブック

Inbound Marketing ハンドブック

Inbound Marketing 概要

Inbound Marketing は、GitLab のマーケティングファネルの最上部で生み出されるビジネス価値を構築・成長・保護するために存在します。GitLab ウェブサイトおよびその他のチャネルを通じた、私たちのコンテンツとのオーガニックなエンゲージメントを通じて、既存および潜在的な GitLab 顧客とのマインドシェアと関係を確立するために活動しています。

進捗の測定

ウェブサイトページビュー

GitLab マーケティングウェブサイト上のページビューを年次累計で 20% 増加させる。

会計四半期累計ページビュー目標実績
Q1FY2223.4M24.4M
Q2FY2247.3MTBD
Q3FY2269.6MTBD
Q4FY2293.8MTBD

GitLab チームメンバーは 内部ダッシュボード を閲覧できます。

Inbound Inquiries (インバウンド問い合わせ)

会計四半期問い合わせ数実績ペース
Q1FY2233,40041,000—-
Q2FY2243,0002021-07-01 時点で 29,30044,190
Q3FY2245,200TBD—-
Q4FY2247,500TBD—-

SSoT: GitLab チームメンバーは 問い合わせのライブ内部ダッシュボード と トライアル を閲覧できます。

定義

inquiry (問い合わせ) は次のように定義されます:

  • ユニークなメールアドレス
  • 過去 180 日以内に送信されたもの
  • 以下の Sisense ソースのいずれかから:
    • Trial - Enterprise
    • Trial - GitLab.com
    • Inbound

計画

Inbound Marketing の計画活動は このエピック で整理されています。現在は年次および四半期のケイデンスで計画を立てており、H2 FY22 では 2 四半期先行で計画する ように移行中です。

目標と主要結果 (OKR)

Inbound Marketing は四半期ごとに OKR を設定し、検討対象となる将来の OKR 候補のバックログも維持しています。

Q2 FY22 Inbound Marketing OKRs

過去の OKR

Brand and Creative の Issue テンプレート

サポートをリクエストする方法については、ハンドブックページ を参照してください。

Inbound Marketing の Issue テンプレート

ビデオの Issue テンプレート

  • 新規ビデオのリクエスト
    • このテンプレートは、まだ制作されていない新しいビデオをリクエストする場合のみ使用します
    • すでに撮影済みの既存コンテンツに対する編集を求める場合は、ビデオ編集リクエスト を使用してください
    • プロセスドキュメントへのリンクのプレースホルダー
  • ビデオ編集のリクエスト
    • 撮影済みの既存コンテンツの編集にこのテンプレートを使用します
    • 新規ビデオには使用しないでください
    • プロセスドキュメントへのリンクのプレースホルダー
  • ビデオアップロードのリクエスト
    • プロセスドキュメントへのリンクのプレースホルダー

GitLab の使い方

Boards

包括的な Inbound Marketing Boards

Triage Board

Triage Board

  • 目標: 余分な情報を含まない、または冗長な Issue を除外する
  • アクション: 次のいずれかへ移動
    • スプリントサイクルに入る mktg-status:PLAN へ移動するか、
    • [mktg-status: blocked] へ移動し、ブロックされている理由をコメントする

Sprint Board

Sprint Board

  • 目標: 期日、ウェイト、優先度、リソースに基づいて取り組むマイルストーンに Issue を割り当てる
  • アクション:

ハンドオフ: ここで Inbound Marketing チームへハンドオフが行われ、各チームのプロセスを実行します

  • 上記を考慮して特定の週へ移動する
    • 以下の場合はバックログへ:
      • 現在のゴールや優先順位に合わない
      • 現時点で時間やリソースがない
      • 単なる興味深いアイデアにすぎない (将来の戦略・戦術のレビュー対象としてラベル付けされる場合があります)
    • バックログに入れた理由をコメントする
    • PR Issue は事前協議なしには絶対にバックログに入れない

Inbound Marketing Leads Overview

Inbound Marketing Leads Overview

  • 目標: 現在のマイルストーンスプリント中の各 Inbound Marketing チームの作業の概要を把握する
  • アクション:
    • 確認して優先順位付けを支援する

ラベル

ラベルは Boards を生成し機能させるため重要です。最低限の使用は mktg-inbound を使い、以下に示すスコープ付き mktg-status ラベルを使用することです。

意味と使い方

チームラベル

  • mktg-inbound
    • Inbound Marketing チーム向けであることを意味します
    • Boards にプルインするのに役立ちます
    • Issue のステータスを示すラベルではありません
    • [Inbound Marketing 内のチームラベル] mktg-search、mktg-content
      • Inbound Marketing グループのスコープの一部である可能性を示します
      • Issue のステータスを示すラベルではありません
      • [サブチームラベル] content marketing、editorial、digital-production、UX-Design、Web-Dev
        • Inbound Marketing チーム内のサブチーム
        • Issue のステータスを示すラベルではありません

ステータスラベル

  • mktg-status::triage
    • Triage は Inbound Marketing 外部 からのリクエストに対して使用します
    • Issue のステータスが、作業パイプラインに入る前のレビュー中であることを示します
    • 作業されるタイムラインを示すものではありません
  • mktg-status::plan
    • Issue のステータスが、必要なすべての詳細についてレビュー済みであることを示します
    • Issue にはマイルストーンもアサインも付与されていません
    • 作業されるタイムラインを示すものではありません
  • mktg-status::WIP
    • Issue がスプリントとアサインに割り当てられ作業されることを示すために使用します
      • 最低限の使用には以下が含まれます:
        • マイルストーン Fri: MONTH DAY
        • ウェイト
          • ウェイト 1 は 半日 を表します
          • ウェイトが 4 を超え始めたら、さらに細分化することを推奨します
        • 1 名のアサイン
          • Issue には 1 名だけをアサインすることを積極的に推奨します。Issue 内で @username を使用することで、Issue スレッド内で他の影響を受ける関係者をタグ付けできます。
  • mktg-status::blocked
    • Issue のステータスが、進めるための情報が不足していることを示します
    • 作業されるタイムラインを示すものではありません
    • これは Triage プロセス、または Issue があまりにブロックされて再スケジュールが必要な場合のみ使用すべきです。
      • Issue がブロックされた場合、Triage プロセスへ戻り、そこからスケジュールされます
  • mktg-status::review
    • Issue のステータスが、ピアレビュープロセス中であることを示します
    • 作業されるタイムラインを示すものではありません

プロジェクト

追加ラベル

  • IM-Support
    • Inbound Marketing 外部の他チームに提供されたサポートかどうかを示します
    • Inbound Marketing が毎年サポートした Issue 数を素早く確認し、予算とリソースリクエストの参考として提供するのに役立ちます。
  • IM-Review-Future
    • 将来の戦略の可能性として Inbound Marketing がレビューする予定です

マイルストーン

意味と使い方

  • Fri: MONTH DAY
    • Issue が作業される週を示します
    • 作業 = より小さい Issue に分解されるか、Issue が完了してクローズされる
  • Inbound Marketing Backlog
    • 現在のゴール、時間、リソースに合わないことを示します - 将来のゴールを情報提供するため後でレビュー可能
    • Issue リクエストがキャンセルされたことを意味するものではありません
  • Case Study
    • ケーススタディ専用
    • 複数月・複数チームにまたがり、終盤近くまで正確にタイムラインを評価できないため作成されました
    • ケーススタディの公開のためにスプリントマイルストーンを持つ新しい Issue が作られます
  • INFORMATION GATHERING
    • 情報収集に使用される Issue ですが、明確な成果物がないことを示します

エピック

これは私たちがプロジェクトを整理するためにエピックを使う方法です。最上位レベルでは最高位の情報を、下位レベルのエピックには具体的な情報を含めることを目指しています。これは SSoT を維持し、複数の場所で更新する必要のある情報の重複配置を避けるためです。

  • トップレベルエピック
  • 第 2 階層エピック
    • チームまたはチャネルの戦略/改善をフェーズに分解して保存
    • 含まれる内容
      • 現状
      • ステークホルダー
      • メトリクス - ベースラインとターゲット
      • 望ましい状態 - 主要オーディエンス + 意図と主要な企業ゴール
      • 改善ロードマップ - 複数四半期にまたがる場合は四半期ごとに分割
      • フェーズ - 四半期ごとに以下を含む:
        • 問題
        • 解決策
        • なぜこの取り組みか
  • 第 3 階層エピック
    • フェーズごとのエピック - フェーズ 1 つにつきエピック 1 つ
    • 含まれる内容:
    • プロジェクトのスコープ
    • 親エピックと異なる場合の役割と責任のチャート
    • 関連ドキュメント
    • 高レベルなエピック制作のみ - 個別 Issue の制作はすべてその Issue 内に配置し、冗長性を避けます
  • 第 4 階層エピック
    • プロジェクトの MVC - MVC 1 つにつきエピック 1 つ
    • 含まれる内容:
      • MVC のスコープ
      • 関連ドキュメント
      • 高レベルなエピック制作のみ - 個別 Issue の制作はすべてその Issue 内に配置し、冗長性を避けます
  • 第 5 階層エピック
    • 制作 Issue

Issue

Issue タイプ

これが Issue とそのスコープに対する私たちの作業方法です

外部

(Inbound Marketing 外部から) REQUEST ONLY ISSUE

  • 複雑なプロジェクト用 (例: キャンペーン)
  • このタイプの Issue は Inbound Marketing 外部 のチームから提出されます
  • 私たちへの簡潔な依頼書として機能します
  • リクエストの種類ごとに、対応する Request [Type] Issue Template があり、プロセスを開始するために記入する必要があります
  • Issue で取られるアクション:
    • すべての情報がレビューされ、すべて揃っていれば mktg-status::PLAN に、揃っていなければ mktg-status::blocked にラベルが変更される
    • 実行するチームメンバーがアサインされる
    • 作業されるスプリント週がアサインされる (作業 = 制作 Issue に分解される)
    • Issue は子エピックに追加され、作成のための実行 Issue が作られる
    • アサインされた人は Request Issue にコメントしてクローズし、子エピック内で作業を提供する

REQUEST AND PRODUCTION ISSUE

  • シンプルな依頼用 (例: 単一アセット)
  • このタイプの Issue は Inbound Marketing 外部のチームから提出され、プロジェクトに関連する情報 AND;
  • Inbound Marketing チーム向けの実行項目/制作チェックリストを含みます
  • リクエストの種類ごとに、対応する Request [Type] Issue Template があり、プロセスを開始するために記入する必要があります
  • Issue で取られるアクション:
    • すべての情報がレビューされ、すべて揃っていれば mktg-status::PLAN に、揃っていなければ mktg-status::blocked にラベルが変更される
    • 実行するチームメンバーがアサインされる
    • 作業されるスプリント週がアサインされる (作業 = 成果物が作成される)
    • アサインされた人は制作チェックリストに従い、元の Issue 内で作業を提供する

内部

(Inbound Marketing 内部)

PRODUCTION ISSUE

  • リクエスト/依頼書を作成・実行するために内部で使用する Issue です
  • これらは Inbound Marketing 内部の人のみが使用します
  • リクエストの種類ごとに、対応する Production [Type] Issue Template があり、プロセスを開始するために記入する必要があります
  • チームはこれらの Issue に個別ピースを提供しますが、完成した依頼内容は提供しません。それは作成された子エピックに提供されるべきです

Issue テンプレート

外部

(Inbound Marketing 外部):

Issue 作成者

  • ハンドブックの指示に基づいてテンプレートを選択
    • テンプレートタグが自動で追加されます:
      • mktg-inbound
      • mktg-status::triage
      • 関連するグループラベル: design、content marketing、または mktg-analytics
      • IM-Support
    • テンプレートには記入を助ける具体的な情報が含まれており、期日選択の指示も含まれます
    • テンプレートには自動アサインがあります
    • 追加情報のためのハンドブックページへのリンク

内部

(Inbound Marketing 内部):

Issue のアサイン先:

  • 依頼書を分解するためのテンプレートを選択
  • テンプレートタグ:
    • 上記の既存タグを保持。ただし、私たちがプロジェクトを開始する場合は MG-Support を削除します
    • チームのプロセスタグを追加
  • 依頼 (外部依頼書 Issue) が 1 件の依頼を必要とする場合:
    • 必要に応じて再アサインし、スプリント週に入っていることを確認し、文書化されたプロセスに従う
  • 依頼 (外部依頼書 Issue) が複数の依頼を必要とする場合:
    • プロジェクトを保持するエピックを作成
    • マークダウンをコピー & ペーストしてエピック説明に貼り、ヘッダー「外部依頼書」を使用
    • Issue とエピックを関連付ける
    • プロジェクトエピックが作成されたことを Issue にコメントしてクローズ
    • プロジェクト内に必要な Issue を構築し、エピックと関連付け、Issue をアサインし、追加の依頼書情報があれば必要に応じてエピックの説明を更新

プロセス

ビデオプレイリスト

非同期コミュニケーションとコラボレーションを可能な限り効果的にするため、Inbound Marketing チームが作成した関連プレイリストを以下に紹介します。チームの役に立つ追加プレイリストやビデオのご提案を歓迎します。私たちの Slack チャンネル でリクエストしてください。

予算

予算管理

  • Allocadia が予算の SSoT です
  • 予算はチームごとに四半期化されます

ベンダー管理

ベンダー採用

ブランドまたはデジタルベンダー (「一人エージェンシー」(別名フリーランス) でもエージェンシーでも) をご存知の場合は、さらなる検討のため、その連絡先をマネージャーと共有してください。

ベンダーオンボーディング

  1. マネージャーが関連する GitLab プロジェクトと Slack チャンネル向けの Access Request Issue を作成
  2. マネージャーが Intro to GitLab Issue を作成
  3. マネージャー、ベンダー、ベンダーバディーの紹介コールで、期待値を設定し、ワークフローの概要を共有し、関連するハンドブックリンクを共有し、最初のプロジェクトを紹介
  4. ベンダーが Intro to GitLab Issue を完了。標準およびデザインまたは開発のオンボーディングタスク (ベンダータイプによる) を含む
  5. 開発ベンダーがコード環境のセットアップに苦労している場合は支援し、コードベースに慣れさせてください
  6. オンボーディングに関する質問は、ハンドブック、マネージャー、または #marketing_brand_contractor_onboarding チャンネルを参照してください

ベンダープロジェクト管理

チーム

  • ベンダーへの Issue アサイン
    • ベンダーと、ベンダーのバディーになるチームメンバーをアサイン
    • 以下のラベルが Issue にあることを確認:
      • vendor
    • 必要に応じて Issue をマイルストーンにアサイン
    • Issue が ベンダーボード に表示されることを確認
    • ベンダー管理エピック でベンダー管理を改善する機会を捉える

ベンダーバディー

  • ベンダー作業の管理
    • 自分とベンダーが Issue にアサインされていることを確認
    • 進捗を確認し、ブロッカーをクリアするため定期的にチェックイン
    • 自分のプロジェクトと同様に、自分がアサインされたプロジェクトが ベンダーボード で維持されていることを確認
    • GitLab の非同期コミュニケーションのベストプラクティスに従い、Issue またはベンダー契約 Slack チャンネル #brand-contractors でベンダーとコミュニケーションを取ってください。GitLab の非同期モデルが請負業者には新しい場合があることも認識してください。ベンダーが非同期作業に慣れる中で、同期ミーティングにもオープンであってください
    • 標準の GitLab および Brand and Digital の作業慣行を満たす。これにはオープンで包括的なデザインと 週次ステータス更新 が含まれます
    • 品質保証のためベンダーの成果物をレビュー
  • 懸念事項への対応
    • 問題が発生した場合、ベンダーへのフィードバックは個別に提供してください。懸念点、解決方法、解決日について具体的にしてください
    • 重大な懸念や問題のパターンはマネージャーと共有
    • 大幅なプロジェクト遅延や作業品質の低下など、緊急の懸念は直ちにマネージャーに報告

ベンダー請求、支払い、レポート

ベンダーバディー

  • ベンダーからの請求関連の質問を適切な相手に振り分けるのに役立てるよう、請求プロセス について十分理解していることを確認してください
    • ボールを落とさないでください。ベンダーが満足し、支払われるようにしたいです
    • 物事が進むよう、すべての質問を最初から最後までフォローしてください
      • 例: 「Coupa で困っています。誰が手伝ってくれますか?」(Accounts Payable Team)
      • 例: 「請求書に発注書番号は必要ですか?」

マネージャー

  • ベンダー契約 - ディレクターの承認を得て、ベンダー契約 を交渉・締結します。ゴールは、割り当てられたベンダー予算内で提供される価値を最大化することです
  • 請求 - ベンダーが以下を満たすようにする:
  • 月次ベンダー作業レポート
    • 進行中のプロジェクトおよび過去 1 か月以内に完了したプロジェクトを含む、ベンダープロジェクトの月末レポートをディレクターに提供

ディレクター

  • 請求書の承認
    • 月中および月末に Coupa で請求書を承認
    • Brand and Digital マネージャーとともにベンダーの請求書と成果物を検証
    • プロジェクトが適切な予算に請求されていることを確認
  • 契約の承認
    • ブランドおよびビジネス目標に沿ってベンダーをエンゲージ
    • 全体の予算支出を管理
  • 月次ベンダー作業レポート
    • 月次ベンダー作業レポートに支出を追加し、認識のためステークホルダーへ配布。ステークホルダーには Inbound のリーダーシップ、Finance、ベンダーと連携している Marketing チームリードが含まれます

メインの Marketing ハンドブック に戻る。

Search Marketing
Search Marketing は、GitLab の公開ウェブサイトへのトラフィックを増やし、コンバージョン率を改善することによって、GitLab の収益成長に注力します
最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License