Microsoft 収益化 - サーバー側 Cookie ストア
セグメントやユーザーが特定のクリエイティブを見た回数などのユーザー データは、ほとんどのキャンペーンのターゲット設定と意思決定プロセスの大きな部分をなしています。 このため、ユーザーに関する一貫性のある包括的なデータは、インターネット環境全体でどこで、いつ、どのように "表示" されているかに関係なく維持する必要があります。
従来、ユーザー データはユーザーのブラウザー Cookie に保存されますが、多くのオークションでは、Microsoft Advertising はブラウザーにアクセスできません。 (たとえば、Exchange からサーバー側の広告呼び出しが渡された場合など)。では、そのユーザーを認識し、複数のサイトやプラットフォーム間で関連するユーザー データにアクセスするにはどうすればよいでしょうか。 これを行うために、Microsoft Advertising Cookie ストア (サーバー側のユーザー データ ストレージ システム) を設計しました。 Cookie ストアとユーザーの同期により、次のことが可能になります。
すべての Microsoft Advertising サプライ パートナー間でユーザー ID と頻度データを同期します。
すべての広告通話でアクセスできるように、お客様と当社のサーバー側の両方の Cookie データを保存します。
注:
Microsoft Advertising Platform によって設定された Cookie の正確な一覧と、その内容の詳細については、「 Cookie」を参照してください。
ユーザー ID のマッピング
Microsoft Advertising のタグが、プラットフォームを通過するすべてのインプレッションに対してすべてのページに含まれている場合は、表示されるすべてのユーザーに対して Cookie にアクセスできます。 しかし、私たちはしません。
たとえば、Google アド マネージャーとサーバー側の統合によってインベントリが渡されるため、Google アド マネージャーは Cookie にアクセスできますが、アクセスできません。 Google アド マネージャーが広告通話を受け取ると、ユーザーを ABC として ID します。 Yahoo Ad Exchange はユーザー 123 を呼び出し、AdMeld は 007 を使用します。 関連するデータを適用し、頻度ターゲティングを適切に規制できるように、これがすべて同じユーザーであることを知る必要があります。
ID マッピングの正確な方法は、統合パートナーによって異なります。 パブリッシャーのページのピクセルを通じて、またはユーザーに広告を配信することで、マップを実行する場合があります。 ユーザー ID マッピングは、データベースに格納することも、データベースに格納することもできます。 統合の例をいくつか次に示します。
- Ad Network X は、マッピングをデータベースに格納します。 Network X は、mysite.com を含む、パブリッシャーのページにピクセルを配置します。 ユーザーが mysite.com にアクセスすると、ピクセルが起動し、Microsoft Advertising はユーザーのブラウザー Cookie でユーザーを 1938 としてマークできます。 また、ピクセルはネットワーク X にリダイレクトされ、Microsoft Advertising がこのユーザーを 1938 に呼び出し、ネットワークのユーザー ID にマップされ、将来の使用のために保存できることを知らせます。
- Exchange Y はマッピングをデータベースに格納しますが、ページにピクセルを配置しません。 代わりに、このユーザーに初めて広告を配信する際に、ユーザーのブラウザー Cookie に一意のユーザー ID を追加する usersync ピクセルを起動し、ユーザー ID を Exchange Y に渡すようにリダイレクトします。
- Exchange Z の場合、Microsoft Advertising は ID マップを格納します。 この場合、Microsoft Advertising が初めてユーザーに広告を配信する際に、Exchange Z にピクセルを起動し、そのユーザー ID を渡します。このユーザー ID は、Microsoft が保存します。 今後の印象では、Exchange Z からユーザー ID が送信され、データベースで検索できるようになります。
データセンター間の同期
重点的に取り組んでいる点の 1 つは、すべてのユーザー データがすべての Microsoft Advertising データ センターで使用できることを確認することです。 現在、ロサンゼルス、ニューヨークのメトロ リージョン、アムステルダムにデータセンターがあり、ユーザーはトポロジ的に最も近いデータセンターにルーティングされます。 つまり、米国の途中のユーザーは、ニューヨークやロサンゼルスにルーティングされる場合があります。 または、あるデータセンターでネットワーク が中断された場合、すべてのトラフィックが他のデータセンターにルーティングされます。
たとえば、North Dakota にクリエイティブを 6 回表示するユーザーがいるとします。 そのうちの 3 回は、ユーザーがニューヨークのデータセンターにルーティングされ、そのうちの 3 回は LA にルーティングされました。
第 7 印象では、ユーザーはニューヨークにルーティングされます。 ニューヨークで記録された 3 回ではなく、このクリエイティブを既に 6 回見たことを知る必要があります。 そのため、セグメント データを前後に渡すことで同期するように LAX データセンターと NYM データセンターを設計し、AMS は独自の Cookie のみを保持しています。
サーバー側セグメント データ ストレージ
セグメント データは、 セグメント を介して渡されるか、オフライン転送を介して渡されるかに関係なく、ユーザーのブラウザーではなく Cookie ストアに格納されます。 このようにして、すべてのインベントリ ソース、サード パーティの交換、およびインベントリ アグリゲーターでセグメント データを使用できます。
また、Batch Segment API を使用してユーザーにアクセスすることなく、いつでもセグメント データを更新できます。