ANNAIマガジン
Acquia ロゴ
この記事は「 Acquia Campaign Studio vs. Salesforce Marketing Cloud Part 2 」の翻訳です。
この記事の目次

アクイア Campaign Studio と Salesforce Marketing Cloud (SFMC) の比較シリーズのパート 2 へようこそ。パート 1 を見逃した方は、こちらでお読みいただけます。第 2 回目のテーマは、この 2 つのツールのコンタクト管理機能を比較します。

SFMC とアクイア Campaign Studio の比較:コンタクト管理

SFMC では、事前にコンタクト管理を設計するための専用リソースが必要です。アクイア Campaign Studio は、CRM データベースと直接同期することができます。どちらのプラットフォームも強力なセグメンテーション機能を備えていますが、ユーザーがデータにアクセスして活用する方法に大きな違いがあります。

まず、SFMC から見てみましょう。コンタクトレコードを利用する方法はたくさんあります。私が最初に SFMC を使い始めたとき、私のチームは Lists だけを使っていました。Lists は、SFMC のシンプルで初歩的なコンタクト機能で、データベースの購読者数が 50 万人未満の場合、サブスクライバーの属性が限られている場合、またはインポートに時間がかかる(XML API を使用している場合)など、「パフォーマンスよりもシンプルさ」を好むマーケティングチームにお勧めです。

私のチームはすぐに、当社のマーケティングロードマップに基づいて、Lists ツールではサポートできないと判断しました。メールオートメーションは、よりパワフルなものでなければ成功させられなかったからです。SFMC では Lists からのアップグレード先は Data Extensions と呼ばれるもので、私たちはそれに移行することにしました。しかし、移行のために Salesforce の専任担当者を配属したにもかかわらず、移行には数ヶ月を要しました。SFMC はリストレベルで重複を削除していないため、一意の識別子が複数レコードと一致してしまうという問題に何度も遭遇しました。さらに、SFMC はレコードを誤って修正し、必要なアカウント番号を削除していたため、エンジニアリングチームとお客様に大混乱を引き起こしました。すべてのマーケティング活動を通じて収集した貴重な顧客行動データを失うわけにはいかないので、Salesforce の専任担当者は、データ拡張機能を使って SFMC ツールでデータウェアハウスを再設計し、ミラーリングすることにほとんどの時間を費やすことになりました。このプロジェクトでは毎週のようにスコープ外の問題が発生し、異なる Salesforce チームの援助を必要とすることになりました。

データ拡張機能について

これまでの経験から SFMC を採用する決め手となったのは、SMFC がフィルタリングや他のリストとの関連付けが可能な、さまざまなデータテーブルを格納できるシステムであるということでした。これを可能にするのが Data Extensions とクエリーツールです。SFMC の Data Extensions の定義は、簡単に言うと「自分のデータを格納したテーブル」です。私が考える Data Extensions の定義は、顧客行動データ、顧客 ID データ、フィルタリングとトリガーデータ、インポートデータ、およびレポートデータ(ピボットテーブルを持つ Excel ドキュメントのようなもの)を必要な数だけ格納できるリレーショナルレコードテーブルです。各々のテーブルは異なる識別子(一意でなくてもよい)を持つことができます。これは、各レコードに何百万ものインスタンスがある場合や、異なるテーブル間で相互に連携する必要がある場合に便利です。ユーザーは Data Extensions を使ってフィルタリングしたり、クエリツールで SQL コードを書いてデータを照合したり、引き出したりすることができます。また、Data Extensionsは、「コンタクト」タブで新しいページを読み込む際のタイムラグを短縮するのにも役立ちます。Data Extensions の検索機能はあまり優秀ではないので、これらをどこにフォルダ分けしてアーカイブするかに配慮する必要があります。しかし一般的には、Data Extensions を自社のデータウェアハウスと比較するのは簡単だと思います。

前述したように、50 万人未満の購読者、限られた購読者属性、遅いインポート速度を持つデータベースには Lists が適切なツールであるのに対し、50 万人以上の購読者を持つデータベースや、グローバルにメッセージを送信し、より速いインポート速度を可能にしたり、SOAP や REST API コールを実行するには Data Extensions が必要です。

Data Extensions を別の観点から考えると、複数のレベルの顧客の行動や履歴データを保存できる場所となります。お気に入りのオンラインショップを思い浮かべてみてください。例えば Zappos は直感的であり、同時にパーソナライズされています。お気に入りにハートをつけたり、過去の検索結果や購入履歴を閲覧したり、それらすべてのエンゲージメントに基づいたおすすめ情報を得ることができます。これらの機能(ハート、検索、購入)はそれぞれ、Zappos のデータベース内の別々のテーブルに格納されています。私は 10 の「ハート」と 3 つの過去の購入履歴を持っているかもしれません。つまり、私のユニークな識別子(この場合はメールアドレス)は、1 つの Data Extension テーブル(「ハート」用)の10 行と、別の Data Extension テーブル(過去の購入用)の 3 行になるということです。以下の画像を参照してください。もし Zappos がハートと過去の購入履歴の組み合わせに基づいて商品を宣伝したいと思ったら、新しい Data Extension を作成し、「ハート」と「購入履歴」のテーブルにクエリーをかけて、新商品の条件を満たすすべてのレコードを取得し、送信リストとして機能させるでしょう。Zappos に新しいレインブーツがあり、関連する顧客に宣伝したい場合、2 つのテーブルを比較して、誰がレインブーツに興味を持っているか(左の「Hearts」テーブル)、誰が似たようなものを買ったか(右の「Purchase」テーブル)を確認します。以下のテーブルの例にある「お客様番号 3 」と私は、それぞれこれらの条件を満たしているので、それぞれ新しいレインブーツのプロモーションを受けることになります。
文章内で触れているデータベーステーブル内容のスクリーンショット

SFMCのコンタクトビルダーとデータデザイナーについて

2013 年に Salesforce が ExactTarget を買収した後、Contact Builder や Data Designer といった機能がプラットフォームに加わりました。Contact Builder は、すべてのスタジオと「アプリ」(たとえば Salesforce CRM システムなど)の間でレコードを結合するためのものです。Data Designer は Contact Builder を機能させるもので、Contact Builder  の「スタジオ」内で使用するツールです。最終的に 1 人の顧客をすべてのアプリ、スタジオ、プラットフォームで 1 つのレコードとして統一したい場合は、Contact Builder でこれを確実に実行する必要があります。新しいクロスチャネルキャンペーンを作成するたびに、Contact Builder が正しく同期されていることを確認する必要があります。私は通常、コンタクトを異なる「スタジオ」に接続することが非常に面倒だと感じていました。新規または更新されたデータ拡張を常に Contact Builder ツールに同期させる必要があるからです。

さまざまなSFMCチャネルで実行できるようにするためには、マーケティング担当者というよりも開発者として行動する必要があると感じました。

アクイア Campaign Studio でのコンタクト管理

アクイア Campaign Studio では、直感的にレコードを連携できる点が気に入っています。Campaign Studio では、データを格納するために理解すべき部分が 2 つだけあります。1 つ目は Contacts で、私はこれをコアテーブルと考えています。2 つ目は Segments です。 セグメント機能は非常に強力で、1 つのセグメントに複数の異なるフィルターを定義することができ、レコードの属性と過去のエンゲージメント行動の組み合わせでフィルターをかけることができます。Contacts では、SFMC Data Extension のように、さまざまなカラムフィールドを作成することができます。しかし、アクイア Campaign Studio では、完全なリストを 1 か所で定義することができるため、別途適用される除外/抑制リストを送信時に気にかける必要がない点が気に入っています。

さらに、アクイア Campaign Studio のセグメントはリアルタイムで更新されるので、リストを手動でインポートした場合、CRM データベースが更新された場合、またはコンタクトが登録された場合などの際には即座に更新され、SFMC で Automation Studio を使用したときのように別の機能に頼る必要がありません。SFMC を使用していたときは、クエリーを実行するのに何時間もかかり、メール送信が遅れることがよくありました。また、SFMC の自動化が失敗したり、時間がかかりすぎたりしたために、競合他社よりも先にコンテンツが配信されることもありました。

最後に、アクイア Campaign Studio には、カスタムオブジェクトという近日公開予定(訳注:記事執筆当時)の機能があります。これは、堅牢で柔軟なデータテーブルを利用できるという点で、Data Extensions とかなり直接的に比較できます。複数のテーブルをフィルタリングやセグメンテーションに使用することができ、それらのテーブルは、SFMC が必要とする余分な開発者の作業をすることなく、お互いに連携することができます。

まとめ

SFMC のユーザーは、Data Extensions がどのように機能し、どのように連携するのかを理解する必要があります。データタイプ、設定の自動化、構文、クエリービルダー、フィルタリングは、時間の経過とともに共通言語になります。Data Extensions は強力で、使いこなせるようにさえなれば、非常に機敏に動作します。もしデータベースに何百万ものレコードがある場合、自動化のタイムアウトやエラーを避けるために、これらのテーブルを使ってデータを適切に操作する方法を知っている必要があります。

それに比べて、アクイア Campaign Studio を使用している場合は、データリストを柔軟に操作することができます。データをどのように表示したいか、フィールドに何をさせたいかを計画するには、前もっていくつかの作業が必要になります。しかし、一度設定してしまえば、アクセスや編集は簡単です。追加のコードを書いたり、開発者を呼んだりする必要はありません。マーケターとして独立して、自信を持ってキャンペーンを実行することができるのです。

 
フッターの採用情報
 
ANNAI株式会社の写真

この記事を書いた人: ANNAI株式会社

ANNAIは、2009年からDrupal専門のWebシステム開発会社として、世界規模で展開するグローバル企業や大学・自治体を中心に数多くのWebソリューションを提供。
CoreやModuleのコントリビューターなど、Drupalエキスパートが多数在籍。国内ユーザーコミュニティへも積極的にコミットし、定期的なセミナーの等の開催を通じて、オープンソース技術の普及や海外コミュニティとの緊密な連携を図っている。
Webシステムの企画・開発〜デザイン、クラウド運用までをワンストップで提供する他、Drupalのコーディングを評価する"Audit業務"や最適なモジュールの調査・選定等、幅広いコンサルティングを行っている。Drupalアソシエーション公式パートナー。

関連コンテンツ