送信ロギングの計画を立てる

学習の目的

この単元を完了すると、次のことができるようになります。

送信ロギングの目的を説明する。
送信ロギングのニーズを評価する。
基本的な送信ロギング計画を作成する。

データを取得する状況

Marketing Cloud Engagement には Analytics Builder やその一連の標準レポートを使用して膨大な情報が示されます。けれども、より具体的なデータを収集し、そのデータに基づいてアクションを実行する必要のある場合があります。そこで登場するのが送信ロギングです! 送信ロギングデータエクステンションは、標準のレポートやトラッキングでは取得できない情報を取得できます。特に特定の送信やその送信の内容に関連する情報です。送信ロギングでは次のような情報を取得できます。

JobID 値と、その他の必要なキャンペーン ID 値やカスタム ID 値がある 1 つの場所
送信に含まれる具体的なデータ (高度にカスタマイズやパーソナライズされたスクリプト化コンテンツを使用する場合を含む)
送信に含まれる重要な値または属性値

こうした情報を使用できれば、送信時にのみ取り込まれる情報を必要とするマーケティング活動が強化されます。ただし、次の制限に留意します。

送信ロギングデータエクステンションで、送信情報を遡って取得することはできません。
送信ロギングデータエクステンションを作成した後で変更することが難しい場合があります。
送信ロギングデータエクステンションが通常の送信プロセス時に大量の情報を取得することがあります。送信ロギングデータエクステンションが極めて大きい場合、送信が遅延し、パフォーマンスに影響する可能性があります。したがって、早期から保持ポリシーの計画を立てる必要があります。

このモジュールでは、送信ロギングを効率的に使用して、送信の遅延、オートメーションの破損、その他の潜在的な問題を回避するために必要なツールについて説明します。極めて重要な最初のステップの 1 つは、前もって計画を立てることです。では始めましょう!

送信ロギングデータエクステンション

まず、送信ロギングデータエクステンションについて説明します。Marketing Cloud Engagement には、メール、SMS、プッシュメッセージ送信用のデータエクステンションテンプレートが用意され、基本的な情報が設定されています。さらに、「Web ページとして表示」機能の URL や、キャンペーンデータなどのカスタムフィールドを追加できます。こうしたデータエクステンションは大量のデータや処理を伴うため、必要なものだけを取得し、同時に複数のプロセスがデータエクステンションを使用しないように綿密な計画を立てる必要があります。その理由は、各 MID (テナントの最上位のアカウントまたはビジネスユニット) のチャネル (メール、SMS、プッシュ) ごとに送信ロギングデータエクステンションを 1 つしか使用できないためです。ですから、使えるものを最大限に活用します。

テンプレート

送信ロギングデータエクステンションは常にテンプレートを使って開始します。どのテンプレートもデフォルトで、送信種別に基づいて次のフィールドが設定されています。

メールテンプレート
JobID	従来のメール送信の数値識別子
ListID	アプリで作成された一意の識別子
BatchID	メッセージングサービスが処理する作業単位の一意の識別子。どのバッチも 1 人以上の購読者で構成されます。
SubID	各メッセージ受信者の購読者 ID
TriggeredSendID	トリガーによる送信の定義の一意の識別子 (トリガーによる送信のみに適用)
ErrorCode	送信で見つかったエラーを識別するコード

SMS テンプレート
SMSJobID	SMS 送信の数値識別子
SMSTriggeredSendID	SMS 送信に関連付けられているトリガーによる送信の数値識別子
BatchID	トリガーによるメール送信イベントに関連付けられているバッチを識別する番号。1 つのジョブを使用する同じ購読者への複数の送信を区別するために使用します。
SubID	各メッセージ受信者の購読者 ID

プッシュテンプレート
PushJobID	プッシュ通知が含まれるジョブ (送信のバンドル) の ID
PushTriggeredSendRequest	API コールから返される TokenID。リストやデータエクステンションを使用して送信する場合は、PushJobID と同じです。
PushBatchID	バッチ送信のバッチ (ジョブのバンドル) の ID
SubID	各メッセージ受信者の購読者 ID
DeviceID	プッシュ通知を受信したデバイスの ID
AppID	プッシュ通知を受信したアプリの ID
LogDate	このデータが送信ログに書き込まれた日付

上記のフィールドには Marketing Cloud Engagement で生成された情報が入力され、値を変更することはできません。

データ形式とデータ型

送信ログは 1 つのデータエクステンションを使用するため、データを最小限に抑えることをお勧めします。極めて大きなデータエクステンションは、データの保存やインデックス付けに多大な時間を要する可能性があるため、データを合理化することが重要です。スピードや効率性を最大限に高めるために自転車を合理化するようなものです。最高のパフォーマンスを目指してベルや吹き流しは取り外します! データエクステンションのパフォーマンスを最適化するためのガイドラインをご紹介します。

可能であれば使用するフィールドを 20 未満にし、どのような場合でも 100 を超えないようにする。
行全体のすべてのフィールドの情報が 3,000 字未満になるようにする。
テキストフィールドの文字数を定義して、フィールドに文字を詰め込み過ぎないようにする。
カスタムフィールドをプライマリキーに設定しない。
送信ログに追加するフィールドはすべて Null 許容にする。

追加するデータを定義したら、保持するデータ量を決定する必要があります。相当な量になることがあります。送信で数百万行のデータが生成される可能性があるため、その量を確実に管理しながら、必要なものは抽出し、残りを削除する必要があります。送信ロギングデータエクステンションの維持に関する以下のガイドラインを参考にします。

不要になったデータや抽出されたデータを、通常は数週間から数か月おきに消去するデータ保持ポリシーを設定する。
保持する行数を最小限にする。
送信ログに書き込まれるデータが 1 日に数百万を超える場合は、Salesforce チームと協力し、その量に合わせて最適化する。
送信ロギングデータエクステンションにデータを保持するのは、長期保存の目的で別の場所にエクスポートするために保存する必要がある期間に限定する。
マーケティング活動を実施するときは、送信ロギングデータエクステンションのデータではなく、長期的なストレージのデータを使用する。

データを取得する場合、送信ロギングデータエクステンションは特定の送信に関連するデータのみを取得し、それ以外は取得しない点に注意します。そのデータを後で他の情報と組み合わせて使用したいときは、ID 値を使用してそのデータを別のデータエクステンションにエクスポートし、データを連絡先レコードと照合できるようにします。

最後に、プログラム言語を使用してデータを取得する場合は、JSON 形式のデータを 1 つのフィールドに保存できます。つまり、1 つのフィールドに相当量の情報を保存して、送信ログデータエクステンションのパフォーマンスを向上させることができるということです。

ビジネスユニット用の送信ロギング

このモジュールの最初に、MID ごとに送信ロギングデータエクステンションを 1 つのみ使用できると説明しました。テナントが複数のビジネスユニットを使用する場合は、情報をログに記録する多数のメッセージを送信ロギングデータエクステンションに送信する可能性が高くなります。そのため、ビジネスユニットごとに送信ロギングデータエクステンションを設定することを検討します。以下に、ビジネスユニット間で送信業務を分担するアイデアをご紹介します。

テスト送信に特化したビジネスユニットを設け、送信データの品質に影響を及ぼすことなく新しいアプローチを試せるようにする。
Transactional 送信に特化したビジネスユニットを設け、Transactional データを分離して、送信ログのエントリを最小限に抑える。
計画的に実施する大規模な一括メール送信に特化したビジネスユニットを設け、こうしたイベントをアドホック送信や Journey Builder ベースの送信と分離して、両方の送信や送信ログの書き込みプロセスがスムーズに継続されるようにする。

さまざまな送信ログを使用すると、必要なすべての属性や関連する送信データを確実に取得できます。

次の単元

送信ロギングの考え方と計画の基本事項を把握できたことと思います。次の単元では、送信ロギングデータエクステンションをアカウントで使用する具体的な方法を見ていきます。