Tokopedia による Google Cloud Platform でのカスタマー データ プラットフォーム（CDP）作成の取り組み

※この投稿は米国時間 2021 年 12 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

Tokopedia は 2009 年に開設された e コマース プラットフォームで、数百万のインドネシアの人々が Tokopedia を利用してオンライン取引を行っています。そして、会社の拡大とともに、プラットフォームのカスタマー エクスペリエンスを向上させるために顧客行動の理解を深めることが急務となっています。現在、Tokopedia における 1 か月のアクティブ ユーザー数は 1 億を超えますが、ユーザー層もユーザーの嗜好も異なっています。このようなユーザーのニーズを満たす方法の 1 つが、カスタマイズです。

通常、ユーザーが欲しい商品を見つけるには、何千もの商品を閲覧しなくてはなりません。Tokopedia は、各ユーザーに関連する商品のおすすめを作成して、ユーザーの検索にかかる時間を短縮します。これにより、検索開始から早めのコンバージョンを増やしたいと考えています。カスタマイズの構築では、データ エンジニアリング チームのカスタマー データ プラットフォーム（CDP）がユーザー属性へのアクセスに貢献しました。データ エンジニアリング チームが開発したこれらのユーザー属性は、部門やチームでのさまざまなユースケースへの対応に役立っています。

以前は、次のような大きな課題が 2 つありました。

1. 迅速性と対応の必要性により、データサイロが拡大　カスタマイズの必要性が会社全体で拡大する中、さまざまなチームが独自のカスタマイズ機能を構築してきました。しかしながら、時間的制限があること、およびチーム間でのコミュニケーションの簡素化が必要であることから、各チームがそれぞれデータ パイプラインを作ることとなりました。この結果、一部の属性は以前には別々のモジュールで構築されていましたが、異なるチームで類似のデータが作成されて重複が発生しました。そして、このような重複により、新たなカスタマイズ機能の開発が鈍化しました。

2. データ定義の不整合　各チームがそれぞれのデータ パイプラインを作成したため、チーム間でユーザー属性の定義が異なるケースが多々あります。このため、会議で誤解が生じたり、異なるチームが同じユーザーに異なる属性値を適用したことで、ユーザー ジャーニーが整合しなくなりました。たとえば、チーム A は user_id 001 を 20 代の女性と評価しました。一方で、異なる属性セットと定義を持つチーム B は、user_id 001 を 30 代の女性と評価しました。このような定義と属性の相違は異なる結果を生み、カスタマイズがばらばらになる可能性があります。その結果、顧客は Tokopedia でのジャーニー中に整合性のない経験をしたり、アクティビティ中に不快な経験をするかもしれません。たとえば、大学生活で必要なものに関連するコンテンツ タイプが 1 セット表示されたのに、別のモジュールでは母親や赤ちゃんに関連するコンテンツが表示される状況を想像してみましょう。

CDP により、現在では各チームがインフラストラクチャを継続的に再構築する必要がなくなりました。同じ属性に必要な処理は 1 度だけで、社内全体のさまざまなチームが使用できます。この結果、開発時間と労力が最適化されます。CDP の別のメリットは、複数のサービスやチーム間で単一の属性定義を得られることです。異なるチームが CDP 内で同じ属性を参照することで誤解の可能性が低減し、チーム間の整合性も向上します。これにより、顧客は Tokopedia のプラットフォーム全体で整合性のある経験を得られ、関連のあるコンテンツが表示されるようになります。

さらに、Tokopedia での CDP プラットフォームの構築には、いくつかの重要な要素が必要です。その取り組みは次のようなものです。

1. 属性リストの定義と作成

このフェーズでは、プロダクト チームやアナリスト チームと協力して、CDP の構築に必要なユーザーの全属性を定義します。プロダクト チームが何人かの関係者にインタビューを行って、ユーザー属性に関するさまざまな見解を把握しました。結果、最初の属性リストには性別、年齢層、所在地などが含まれることになりました。このプロセスは、ユーザーの属性を最大限理解するために何度も繰り返されます。

2. プラットフォーム設計

包括的なレビューを行った後、いくつかの GCP 技術スタックを使用して CDP プラットフォームを構築することが決定されました。

CDP セルフサービスの分析バックエンドとして、BigQuery が選択されました。一方で、Google Cloud BigTable がバックエンドとして選択されました。ここで、カスタマイズを可能にするサービスが提供されます。BigTable のストレージの開発では、スキームの設計が非常に重要です。頻度と分類は列修飾子の設計に影響する一方、CDP 属性は行キーの設計に影響します。

また、類似の読み取りアクティビティで BigTable にかかる負荷を低減するため、キャッシング メカニズムも作成しました。特定の有効期間（TTL）で redis を使用して、キャッシュ システムを構築し、最適なパフォーマンスを確保しました。さらに、CDP の属性へのさまざまなサービスのアクセス制御ができるように、CDP API のロールベースのアクセス制御（RBAC）メカニズムも適用しました。

3. モニタリングとアラート

CDP の構築においてもう 1 つの重要点は、適切なモニタリングおよびアラート システムを開発して、プラットフォームの安定性を維持することです。各指標でのソフトとハードのしきい値が設定されてモニタリングされます。このしきい値に達すると、通信チャネルを通じてすぐにアラートが送信されます。現在のアーキテクチャでは、モニタリングとアラートを有効にするために必要な部分がいくつかあります。

• データ パイプライン
  モニタリングが必要なものの 1 つが、コンピューティング中のリソース消費量と、データソースから CDP ストレージへのデータ パイプラインです。データ コンピューティングとデータ パイプラインでは BigQuery と Dataflow を使用して稼働するためです。BigQuery では、スロット使用率をモニタリングする必要があります。スロット使用率は、属性作成で一部のデータの集約と操作をコンピューティングするために使用されます。

• データ品質
  CDP の構築で信頼性の高いプラットフォームを実現するには、高品質のデータが重要でした。データ品質面で重要な指標には、データ完全性、データ有効性、データ異常値、およびデータ整合性があります。そのため、これらの指標を保証するには、複数のモニタリングを有効化する必要があります。

• ストレージと API パフォーマンス
  CDP のバックエンドと API はいくつかの前面機能と直接対応するため、CDP サービスの可用性の確保が必要です。バックエンドとして BigTable を使用しているため、CPU、レイテンシ、および RPS のモニタリングが不可欠です。この指標はデフォルトで BigTable モニタリングで提供されます。

4. 社内全体での検出可能性

これまで数多くのユーザーが、CDP の提供する属性の参照方法を問い合わせてきました。当初、Tokopedia では、属性をドキュメントにして関係者に共有することから始めました。しかし、属性の数が増加するにつれ、ドキュメント内を探すことが次第に困難になりました。このため、CDP 用語の Data Catalog への統合を開始しました。この場合、Data Catalog は、各属性の定義やデータの取得方法を含め、CDP の属性をユーザーが参照できるようにするうえで重要な役割を果たします。

5. プラットフォームの実装と導入

CDP 導入の成功において重要な点として、フロントエンド サービスにおけるチーム間のコラボレーションもあげられます。Tokopedia での CDP 導入には、カスタマイズ、マーケティング分析、セルフサービス型の分析といった複数のタイプがあります。

• カスタマイズ
  CDP が最も一般的に使用されるのは、ユーザーのジャーニーのカスタマイズでしょう。カスタマイズの一例が検索機能です。プロダクト チームは、ユーザーの検索結果をユーザーの住所に基づきカスタマイズします。これにより、ユーザーは、所在地に近い製品を見つけることができます。ユーザー住所の定義を話し合った後、開発を並行して行えるように、検索チームとの CDP API コントラクトを作成しました。その結果、ユーザーはそれぞれの所在地に基づき、より良いユーザー エクスペリエンスを得られるようになりました。

• マーケティング分析
  CDP プラットフォームの構築開始時、既存のユースケースについて、マーケティング チームと話し合いを行いました。その目的の 1 つは、マーケティング活動のカスタマイズと最適化でした。たとえば、ユーザーの属性に基づいて適切なユーザーに通知を送信し、無関係なユーザーへの不要な通知費用を削減すること、スパム通知を回避して総合的なユーザー エクスペリエンスを向上させることです。ニーズを把握した後は、CDP がそのようなニーズにどのように対応するかを検討しました。CDP プラットフォームへの分割エンジンと通信チャネルの統合方法、マーケティング プッシュ通知送信時に使用するユーザー属性のタイプ、そして、CDP プラットフォームの分割エンジンおよび通信チャネルとその属性タイプとの統合方法について、関係チームとの議論が行われました。

• セルフサービス型の分析
  CDP は、特定のセグメントにおけるユーザーの層と動作について分析情報を迅速に得られるように、セルフサービス型の分析も頻繁に使用します。このセルフサービス型の分析ツールを構築するため、プロダクト チームとアナリスト チームと相談し、ビジネス / 製品ユーザーが分析情報を得るために選択することの多いユーザー層の属性を定義しました。必要な属性を把握した後、ビジネス インテリジェンス チームと話し合い、エンドユーザーの可視化を行いました。これにより、さまざまなチームがユーザーの理解を深め、プラットフォームの向上方法について分析情報を得ることができました。

CDP 導入は、さまざまなユースケースに大きな影響を与え、Tokopedia がデータドリブン企業としてさらに進化を遂げるうえでも役立ちました。CDP を通じて、Tokopedia の核の DNA の 1 つである「Focus on Consumer（顧客中心主義）」を強化できます。CDP フレームワークを共有することにより、価値あるものをお届けするとともに、優れた CDP プラットフォームをより簡単に作成できるよう他の皆様のお役に立てればと願っております。

- Tokopedia データ エンジニアリング リード Kent Stanley 氏