Contents
概要と対象読者
個人ブロガーやアフィリエイターが17LIVEアフィリエイトプログラムに参加する際の実務フローを、申請準備から計測実装、運用改善まで整理します。審査で落ちないためのポイントやトラブル対応テンプレートも含め、実務で使える形に簡潔化しました。
対象読者
本記事は次の読者を想定しています。
- これから17LIVEアフィリエイトプログラムへ申請する個人／小規模運営者
- 既に承認済みで計測実装や不具合対応を行う担当者
成果定義と計測の基本
成果（クリック／インストール／課金）の一般的な定義と、計測フローの基礎を説明します。プラットフォームによって用語やパラメータ名は異なるため、以下は一般化した説明と「例示」である点を強調します。
成果の一般的な定義
クリックは誘導トラフィック発生点、インストールは端末へのアプリ導入、課金はアプリ内決済を指すのが通常です。報酬はこれらのイベントがプログラム規定の条件を満たしたときに発生します。
- クリック：アフィリエイトリンクのクリック記録（ブラウザ側やプロキシ側でのパラメータ保存）
- インストール：ストア計測やSDK/S2Sで検知されたアプリ導入
- 課金：注文IDや決済確定のイベントで検証される購入行為
計測窓（アトリビューションウィンドウ）や重複計測の扱いは必ずダッシュボードの定義を優先してください。
計測方式の基本フロー（テキスト図）
計測の主要な流れをテキストで示します。パラメータ名はプラットフォーム依存で、以下は理解のための一般形です。
クリック → リンクにパラメータ付与（例: {partner_id}, {click_id}, UTM） → ランディング → インストール検知（SDK または ストア） → 成果通知（S2Sポストバック／SDK経由） → ダッシュボードで承認・確定
この流れを自分のダッシュボード仕様に沿ってマッピングしてください。
計測時の注意点
計測実装でよく問題になるポイントをまとめます。各項目はダッシュボードの仕様に合わせて実装・検証してください。
- パラメータ名はダッシュボードで指定されたものをそのまま利用すること（以下の例は任意の名称です）。
- click_id の永続化（Cookie/localStorage/サーバー保存）と、成果通知時にその値を返す仕組みを確保する。
- UTM は集計補助であり、アトリビューションはMMPやプラットフォーム側のロジックが優先される点に注意する。
- 計測ウィンドウ（例：インストールはクリックから7日など）はプログラムによって異なるため、ドキュメント確認が必須。
参加資格・審査準備・申請手順
参加条件や審査で見られる点、申請時の実務的な入力・添付準備を一つにまとめます。重複を避け、承認までの流れを実務寄りに整理しています。
審査で重視されるポイント
審査側が確認する代表的項目を列挙します。これらを満たすことで通過率が上がります。
- 申請情報と運営チャネルの整合性（リンク先の内容が申請内容と一致していること）
- コンテンツ品質（オリジナルで利用者の役に立つか）
- トラフィックやフォロワー実績（必要に応じてログや解析データの提示）
- プライバシーポリシー・問い合わせ窓口の明記
- 禁止コンテンツが含まれていないこと（違法・過度に成人向けなど）
審査期間は状況により変動するため、余裕をもって申請してください。
用意すべき書類・アカウント情報の例
申請で一般的に求められる項目をまとめます。提出書類はプログラム仕様に従ってください。
- 個人：本人確認書類、銀行口座情報（名義）
- 法人：登記簿、代表者の身分証、法人名義口座情報
- 税務関連：請求書対応可否や必要書類の有無
- プロモーション情報：運営チャネルURL、月間PV/フォロワー数、主要KPIのスクリーンショット等（数値は直近期間を明記）
- サンプル素材：想定LPやサンプル投稿、プロモーション計画書
誤記のないよう二重チェックし、インセンティブ誘導を行わない旨を明記しておくと審査で有利です。
申請フォームの入力の実務的コツ
申請フォーム記入時の実務的な注意点をまとめます。簡潔かつ正確に記載してください。
- 運営チャネルURLはトップページよりも、実際にプロモーション予定のページを明示する。
- 実績は集計期間を明記して提示する（例：直近3か月の平均月間PV）
- 想定プロモ方法は具体的に（記事、動画、SNS投稿など）記載する
- 添付資料は必要最小限で見やすく、ファイル名に内容を含める
申請後はダッシュボード発行・リンク取得・テスト流入という順で進みます。
リンク発行と計測実装（一般的な実務）
ダッシュボードで発行されるリンクを基準に、汎用的なパラメータ運用とS2S/SDK連携の指針を示します。ここでの例は説明用であり、ダッシュボード仕様を最優先してください。
リンク運用の基本
発行されたアフィリエイトリンクは基本的にそのまま利用し、チャネル別の検証目的で追加パラメータを付与します。ただし追加パラメータの上書きが禁止される場合があるため注意が必要です。
- ダッシュボードで発行されたベースURLは改変しない。
- 集計用にはUTMを併用（分析用）、ただしアトリビューションにはプラットフォームのclick_id等が使われることが多い。
- sub_id/creative_id などで記事や広告クリエイティブを識別する。
パラメータの一般例（必ずダッシュボード仕様を確認）
以下は説明のための汎用例です。実際の名称・順序は各プラットフォームで異なりますので、ダッシュボードの命名ルールに従ってください。
例（汎用表記）:
- https://partner.example/redirect?{partner_id}={あなたのID}&utm_source={チャネル}&utm_medium={媒体}&utm_campaign={キャンペーン}&{sub1}={任意値}&{click_id}={自動付与値}
上記の {…} 部分はプレースホルダです。実際はダッシュボードが指定するキー名に置き換えてください。
S2Sポストバックの汎用フォーマット（例示）
ポストバックはサーバー間通信で成果を通知する方式です。以下はフィールド例です。必ずパートナー側の受信仕様に合わせて実装してください。
- GET/POST パラメータ例（汎用）: {event}={conversion}|{click_id}={保存した値}|{amount}={課金額}|{currency}={通貨}|{order_id}={注文ID}|{timestamp}={UTC時刻}
postback の受信ログと送信ログはトラブル時に重要な証拠となります。
計測検証の手順（実務）
実装後は以下を順に検証してください。ログや時刻を控えることが早期解決につながります。
- リンククリック時に付与されるパラメータをブラウザのネットワークログで確認する。
- click_id を保存しているか（Cookie/ローカル/サーバー）を検証する。
- インストール／課金発生時に postback が届いているかサーバーログで照合する。
- ダッシュボードの数値と内部ログの差異を確認し、必要な情報をサポートに提供する。
禁止行為と公式素材の実務的な扱い方
規約違反は報酬取消やアカウント停止のリスクがあります。ここでは具体例とブランドガイドの入手・申請手順を提示します。
具体的な禁止行為（実務例）
禁止されやすい行為と、その理由を簡潔に示します。違反は即時ペナルティとなることがあります。
- 自己クリックや自動化スクリプトによるトラフィック生成
- クリック購入やクリックファームの利用
- 報酬を条件とした直接的な金銭還元・ポイント付与の誘導
- クローキングや虚偽のランディングページ（誤誘導）
- 他者の権利を侵害する素材の無断使用・改変
- 個人情報を不適切に収集する仕組み
違反が疑われると調査・報酬の取り消し・契約解除の対象になり得ます。
公式素材の入手方法とブランドガイドの確認手順
公式素材は多くの場合、承認後のパートナーダッシュボードで提供されます。入手できない場合の一般的手順は次のとおりです。
- 承認後にパートナーダッシュボード内の「素材」や「Brand Assets」を確認する。
- ダッシュボードに用意がない場合はサポートへ「素材提供のリクエスト（パートナーIDを明記）」で依頼する。
- 承諾されたブランドガイドに従う（ロゴの色・余白・最小サイズ、禁止例の明示など）。
ブランド利用でよく起きるNG例（具体）：
- ロゴの色を反転・大幅に変更して使用する
- ロゴに過度な装飾やキャッチコピーを被せる
- 公式にないバナーを勝手に「公式」表記で公開する
公式表現ルールに従い、誤解を招く表現は避けてください。
開示文（表示例）
アフィリエイトであることを明示する簡潔な表示例を示します（文言は例示）。
- 「当サイトは17LIVEアフィリエイトプログラムに参加しており、リンク経由で登録や課金が発生すると報酬が支払われる場合があります。」
表示場所は記事本文の冒頭または末尾、動画なら説明欄など見やすい箇所が望ましいです。
運用・効果測定・トラブルシューティング
チャネル別運用の基本、KPIの見方、タグ検証、トラブル時の切り分け手順と問い合わせ用テンプレートを実務寄りに提示します。
チャネル別の実務ポイント
各チャネルで効果が出やすい実務の要点を簡潔に示します。チャンネル特性に合わせて導線・CTAを調整してください。
- ブログ：レビューや比較記事、分かりやすいCTA、モバイル最適化を重視する。
- YouTube：デモや事例紹介、説明欄／固定コメントに追跡リンクを設置する。
- X（旧Twitter）：スレッド解説やピン留めで常時露出。
- Instagram／TikTok：短尺で興味を引き、プロフィールのリンクでLPへ誘導。
- LINE公式：セグメント配信で既存フォロワーに案内、過剰通知は避ける。
- 広告：媒体ポリシー（ブランド名の入札可否など）を事前確認する。
主要KPIとA/Bテストの実務
運用で重要なKPI計算式とA/Bテストの基本手順を示します。データの取り方を統一することが重要です。
- CTR = クリック数 / インプレッション数
- CVR（クリック→インストール） = インストール数 / クリック数
- 課金率 = 課金ユーザー数 / インストール数
- eCPI = 広告費 / インストール数
- eCPA = 広告費 / 課金数
A/Bテストは仮説設定→均等分配→十分なサンプル確保→有意差判定→本採用の流れで行います。
トラブルシューティングと問い合わせテンプレート
報酬未反映や不一致が発生したときの一般的な切り分け手順と、サポートへ送る際の含めるべき情報テンプレートを示します。これで一次対応がスムーズになります。
切り分けの一般手順：
- クリック時のタイムスタンプとクリック先URL（パラメータ含む）を確認する。
- 保存している click_id / サブID の有無と保存先を確認する。
- インストール／課金時の注文IDや決済確認ログを確認する。
- サーバーのpostback送信ログと受信ログを突合する。
- ダッシュボードの該当行（時間帯・ユーザー情報）とログを照合する。
サポートへ送るときに含めるべき情報（テンプレート）：
- 件名（例）: パートナーID {あなたのID} — 報酬未反映（click_id={該当ID}）
- 本文（要点）: 発生日時（UTC）、問題の概要、期待する挙動と実際の挙動
- 必須情報（箇条）: click_id / sub_id / UTMs、クリック時の完全なURL、クリックタイムスタンプ、端末OSとアプリバージョン、ストアの注文ID（課金がある場合）、postback送信ログの抜粋（時刻とペイロード）、自側で確認したログの該当タイムレンジ
- 再現手順（可能な範囲で）: どのクリエイティブ → どのリンク → 期待される動作
上記を揃えると調査が早く進みます。スクリーンの画像指定等はダッシュボードの案内に従ってください。
用語集と計測フロー（初心者向け）
計測やアフィリエイト運用でよく出る専門用語を簡潔に説明します。まず基礎用語を押さえ、次にクリックから成果計上までの流れを確認してください。
click_id
クリックごとに発行される識別子です。後続の成果をこの値で紐付けることで正確な帰属が可能になります。
UTM
マーケティング用の計測パラメータ群（utm_source等）で、流入元や媒体を解析するために使います。アトリビューションの主データではない点に注意してください。
S2S（サーバー間通信）
サーバー間で成果情報を送受信する方式です。SDKを使わない場合でも安定した計測が可能となる利点があります。
ポストバック（postback）
成果発生時にプラットフォームがパートナーの受信URLへ通知する仕組みです。受け取ったパラメータを内部DBで照合して承認処理を行います。
SDK
アプリに組み込む計測用ライブラリで、インストールやイベントを直接収集できます。実装時はバージョンとプライバシー要件に注意してください。
アトリビューションウィンドウ
クリックと成果の関連を許容する期間（例：クリックから7日）。プラットフォームによりウィンドウ長が異なります。
KPI関連（CTR/CVR/eCPI/eCPA）
運用評価で用いる指標群です。定義を統一して比較することが重要です。
簡易フロー（テキスト図）
クリック → ランディング（パラメータ保存） → インストール検知（SDK/ストア） → 成果発生（課金） → postback送信 → ダッシュボードで承認
この流れを自身の実装に落とし込み、各ポイントでログを確保してください。
申請から初回運用までのチェックリスト
申請前から初回のテスト流入までに優先すべき実務項目を整理します。短期間で検証を回すための最小限リストです。
- 公式の参加対象国・条件をダッシュボードで確認する。
- 必要書類（本人確認・銀行情報等）を準備する。
- 運営チャネルの代表ページと投稿サンプルを準備する。
- プライバシーポリシーと問い合わせ窓口を用意する。
- ダッシュボード発行のリンクをそのまま利用し、UTMやsub_idで検証用パラメータを付与する。
- click_id保存とpostback受信のログ周りを実装・検証する。
- 承認後はまず1チャネルで小規模テストを行い、CTR/CVR/課金率を確認する。
- 数値を基にA/Bテストを計画し、改善を繰り返す。
参考リンクと注意点
公式ドキュメントと信頼できる解説記事を優先して参照してください。以下は一般的に参照されるページ例です（リンク先の条件や用語は随時更新されます）。
- 17LIVE 公式サイト: https://17.live/
- 参考解説（事例・運用ノウハウ）: https://app-tatsujin.com/17live-affiliate-guide/
- 認証ライバー契約の参考記事: https://avex.jp/livestar/magazine/17live4_official_liver
注意点（再確認）：
- 記載の数値や支払い条件・報酬単価は説明用の例示であり変動します。必ずダッシュボードや公式規約を優先してください。
- パラメータ名やpostbackの形式はプラットフォーム依存です。実装前に公式マニュアルを確認してください。
- 不明点や重大な不一致はダッシュボードのサポート窓口に上記テンプレートを添えて問い合わせると対応が早くなります。
まとめ（重要ポイントの整理）
申請前はチャネルと書類を整備し、申請フォームは正確かつ具体的に記載することが重要です。計測はダッシュボードで定義されたパラメータ名を最優先に扱い、click_idの保存とpostbackの突合で不一致を防いでください。禁止行為やブランド利用ルールを守ることで審査通過率と運用の安定性が高まります。