データをクリーンアップする

学習の目的

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

健全なデータベースの重要性について説明する。
データを改善し、ベストプラクティスに従う。

クリーンなデータ

緊急事態への備えが万全でも、データが不良であれば意図したユーザーとコミュニケーションをとることができません。Harvard Business Review によると、米国の企業は不良なデータの埋め合わせや修正に 3000 億ドル相当の時間やリソースを浪費しているということです。この顕著な例として、メールマーケティングで、情報が不適切なため送信されない連絡先の分もメールプロバイダーに料金を支払っている場合が挙げられます。データ評価を実施して会社の状況を確認します。あるいは、データの健全性には常に向上の余地があると想定するのも 1 つのやり方です。

データベースオブレコード

データの向上に取り組む場合、何から始めればよいのでしょうか? まず、データベースオブレコード (DBOR)、つまり、お客様に関する最も正確かつ最新の情報を保存する場所から説明しましょう。その第一歩は、DBOR が顧客情報の信頼できる情報源であることを全員 (一人残らず) が認識し、そのうえで実際に DBOR を活用することです。生活の変化 (お客様の転居、名前の変更など) に伴ってデータは常に変化します。会社に不良なデータが生じるのは、ある場所で些細な変更をすばやく行ったまま、DBOR を更新せずにいる場合です。

たとえば、Cumulus Bank では Sales Cloud を DBOR として使用しています。Cumulus のある支店長が Marketing Cloud Engagement にインポート中のデータに誤字があるのを見つけました。その際、Sales Cloud にログインしてお客様の元のレコードを訂正する代わりに、スプレッドシートを更新して Marketing Cloud Engagement にアップロードしました。大したことではないように思えるかもしれませんが、こうした些細な食い違いが長期的に大きな影響を及ぼす可能性があります。

データの健全性を優先事項にする

今後は、日常的なワークフローでデータの健全性を優先事項にします。ここで、潜在的なリスクと、データの品質を向上させるための対策を見ていきましょう。

状況	リスク	アクションステップ
顧客情報の変更	Marketing Cloud Engagement のレコードが重複する情報が間違っているため、購読者にメールを送信できない	DBOR を毎日更新する。Marketing Cloud Engagement でお客様のデータが変更されたときに、データベースオブレコードを更新するオートメーションを作成します。外部システムを更新する。Marketing Cloud Engagement が DBOR である場合は、外部の FTP に更新済みのファイルを送信するオートメーションを作成します。この処理は API でも実行可能です。
非アクティブな購読者	メールサービスプロバイダー (ESP) で配信到達性の問題が生じ、アカウントにフラグが設定される	再エンゲージメントキャンペーンを試行する。未エンゲージ購読者にメールでエンゲージしてみる価値はあります。反応がなければリストから削除します。メールの頻度を変更する。非アクティブな購読者には送信するメッセージ数を減らします。件名をテストする。別の件名にしてみることを検討します。オファーでテストする。お得なオファーを記載した離脱メールを送ってみます。
オプトアウトした購読者	システムが送信前にオプトアウトしたメールアドレスを確認する必要がある場合、処理時間が増大する	リストを整理する。送信データエクステンションからオプトアウトした購読者を削除します。
MC Connect の同期	システムが Marketing Cloud Engagement で使用されていない連絡先を同期する必要がある場合、処理時間が増大する	連絡先を削除する。Sales Cloud に必要のない連絡先は、Marketing Cloud Engagement と同期する前に削除します。同期設定を調整する。送信やパーソナライズで使用する連絡先や情報のみを同期します。

データの重要性

データがクリーンであることは大切です。そのデータが高速処理されれば言うことありません。そのため、アカウントの最適化やメール処理の高速化につながるデータストレージのベストプラクティスを確認します。

命名規則を確立し、アカウントのデータエクステンション数を制限する。

アカウントに設定できるデータエクステンション数に制限はありませんが、多すぎると UI と API の両方のアクティビティでアカウントのパフォーマンスが低下する可能性があります。命名規則を導入して、不要なデータソースを減らし、アカウントを整理します。命名規則に、キャンペーンや日付など組織にとって意味のあるものを基準にデータを整理する方法を反映させます。命名規則の一貫性を維持し、頻繁に見直します。

提案: 一時的なデータエクステンションを識別しやすくするために、エクステンション名の末尾に _DELETEME などの命名規則を使用するとクリーンアップしやすくなります。もう 1 つの提案は、テスト用には _QA、最終版には _FINAL などを使用してデータエクステンションを識別することです。

保存するデータの量とコンテンツタイプを制限する。

SQL のパフォーマンスとデータの処理時間を改善するために、システムに保存するデータ量を制限します。キャンペーンのセグメンテーションやパーソナライズに使用するデータのみを保存します。さらに、機密データや個人識別データ (誕生日、社会保障番号など) は、不可欠な場合のみ保存します。Marketing Cloud Engagement にあらゆる種類のデータをインポートできるからといって、そうするべきだということはありません。

列の長さを制限し、正しい種別のデータエクステンションを使用する。

データエクステンションの列は、保存するデータの最大サイズに合わせて設定します。また、保存するデータに基づいて適切なデータ型を使用します。たとえば、誕生日を保存する場合は、テキスト型ではなく日付型を使用します。唯一の例外は SubscriberKey で、数値を使用する場合でも、テキスト列としてシステムに保存されます。

例: 列に 2 桁の都道府県コードを保存する場合は、デフォルトの 50 文字のままにせず、2 文字に制限します。

テーブル全体のサイズを制限する。

パフォーマンスを最大限に高めるために、テーブルの合計バイトサイズを 8,000 文字未満に収めます。バイトサイズは、データエクステンションのすべての列の長さを合算して算出されます。

例: 100 文字の列が 20 ある場合は問題ありませんが、1,000 文字の列が 8 つある場合はこの制限を超過します。

更新または追加されるデータエクステンションにプライマリキーを作成する。

プライマリキーは、この特定のデータエクステンションに一意の行を定義するために使用します。上書きオプションを使用しないインポートまたはクエリにはプライマリキーが必要です。唯一の例外はトリガーによる送信データエクステンションで、再試行時にシステムが同じデータを 2 回再送信しようとする可能性があるため、このデータエクステンションにはプライマリキーを追加しないでください。

例: 送信可能データエクステンションの Subscriber_Key、商品ルックアップテーブルの Product_ID、郵便番号に基づく地域ルックアップテーブルの ZipCode

すべてのデータを更新するのではなく、新しいデータがあるもののみを更新する。

データの処理時間を短縮し、ファイルサイズを削減するために、データの上書きではなく、データエクステンションの追加機能や更新機能を使用します。

例: Cumulus Bank では、その日の顧客アクティビティのファイルを Marketing Cloud Engagement にアップロードしています。処理を容易にするために、社内のデジタルマーケティング担当者が IT チームに、デルタまたは変更されたレコードのみを記載した小規模なファイルが毎日配信されるようにして欲しいと依頼しました。

ビジネスユニット全体で共有データエクステンションを使用する。

データの複数のコピーをクエリまたは作成すると不一致が生じる可能性があるため、共有データエクステンションを使用して、他のビジネスユニットもデータを使用できるようにします。

例: Cumulus Bank の親アカウント (その法人アカウント) には高リスク顧客用の共有データエクステンションがあり、すべてのビジネスユニット (同行の支店) と共有しています。法人アカウントで最新情報を格納したデータエクステンションを管理しているため、各支店は必要なときに最新情報を確認できます。

データ保持

データの健全性を維持するごく簡単なオプションの 1 つが、保持計画を作成して、アカウントのデータエクステンションの数と保存するデータの量を制限することです。Marketing Cloud Engagement でデータエクステンションを作成するときに、特定のデータを削除するか、データエクステンション全体を削除するかを選択して、データ保持の適用方法を選択できます。

次のアドバイスに従います。

データが不要になったときにデータの期限が切れるようにする。
不要になったデータエクステンションを定期的に自動削除する。

データの管理についての詳細は、「Marketing Cloud Engagement データ管理」モジュールを参照してください。

準備完了

緊急事態に備えるためには、会社の資金を節約することのほか、データの健全性やストレージを確認することも重要な要素です。防災リュックに入れた食品の賞味期限をチェックするようなものです。次の重要な原則に留意します。

アカウントを定期的に評価する。Marketing Cloud Engagement アカウントの監査を実施して、頻繁に見直します。
データの健全性の確保に取り組む。会社のデータベースオブレコード (DBOR) から不正確、不完全、不適切な形式、重複しているデータを削除します。
送信リストを整理する。購読者リストを定期的に確認し、エンゲージしている購読者のみに送信するようにします。

これで準備万端です! アカウントを見直し、対処する必要があるリスクを特定し、アカウントの緊急事態への準備を整えることができました。そのうえで、日常の真摯な取り組みにより、緊急事態そのものが回避されることを願っています!

ヘルプをお探しですか?

もっと探す