header_image

はじめに

こんにちは、技術本部・MA部・MA開発1ブロックでマーケティングオートメーションのシステムを開発している長澤（@snagasawa_）です。この記事ではパーソナライズ配信におけるルールベースの最適化を改善した事例を紹介します。

ZOZOTOWNでは、マーケティングオートメーションによってキャンペーンやセール情報などの配信を日々行なっています。配信はその対象によって2種類に大別でき、特定のユーザーセグメント向けの「マス配信」と、個別のユーザーに最適化された「パーソナライズ配信」があります。

この後者のパーソナライズ配信において、既存の最適化処理である課題を抱えていました。それは、特定の条件下でユーザーへ配信が行われずに機会損失が発生するというものでした。今回はこの課題の原因となっていた実装の依存関係を見直し、配信のKPIを改善した事例について紹介します。

ルールベースの最適化の課題

はじめに、パーソナライズ配信の最適化フローと今回改善した課題を紹介します。

最適化フローの概要は過去のテックブログ記事でも紹介していますので、配信システムのアーキテクチャや構成要素も合わせてこちらの記事でご確認ください（過去の記事で「リアルタイムマーケティングシステム」と呼んでいるものを、この記事では最適化の側面から「パーソナライズ配信」と呼んでいます）。

techblog.zozo.com

この最適化フローでは、「チャネル」「時間」「通数」の3つの最適化を行なっています。

処理名	処理内容
チャネル最適化	メール・LINE・アプリPushの中で、ユーザーが最も反応しやすいチャネルを配信先に選択します。
時間最適化	ユーザーが反応しやすい時間帯に配信時間を調整します。
通数最適化	過剰な配信によってオプトアウトされないように、ユーザーごとに一定期間内の配信通数の上限を設け、達していた場合は配信しないように制御します。

課題が存在したのは、ひとつ目のチャネル最適化です。

処理の順序として、チャネル最適化後に通数最適化を行なっていたため、ユーザーの反応しやすいチャネルが選択されたものの、通数最適化で通数上限に達していた場合に配信されないという事象が発生していました。

具体例で言うと、あるユーザーの最適なチャネルとしてメールが選択されたものの、そのメールの通数上限に達していたために配信されなくなるという流れです。

optimization_sample

これは通数最適化の目的からすれば意図した挙動だと思われるかもしれません。しかし、これには改善の余地があります。それは、最適化されたチャネルの「次の優先順位のチャネルでの配信」です。

先ほどの例であれば、メールの次に反応しやすいチャネルがLINEだった場合、そのチャネルで配信し直すという処理です。言われてみれば実装されて然るべきだと思われるような機能ですが、修正前までは未実装でした。

また、加えてもうひとつの課題がありました。最適化フローは過去の配信実績に基づいて行われるため、すでに配信実績のあるチャネルに偏りやすいという課題です。例えばあるキャンペーンが新しい配信チャネルに対応したり、ユーザーのチャネルの利用動向が変化したりしても、過去に最も利用されていたチャネルで配信されやすい傾向にありました。設定によりチャネルの優先度に補正をかけることも可能ですが、その都度補正を調整する手間がかかります。

もしも「次の優先順位のチャネルの配信」が実装されていれば、配信実績のあるチャネルで通数上限に達した場合でも、配信実績の少ないチャネルでの配信が期待できます。

最適化のフロー

先に改善の結論を言うと、通数上限チェックをチャネル最適化の処理内へ移行し、通数の上限到達済みチャネルを選択肢から除外するように修正しました。改善は至ってシンプルです。続いて、最適化フローを詳しく説明します。

最適化の前処理

最適化の前処理として、「イベント検知・キャンペーン判定・ユーザー抽出」の3つがあります。

処理名	処理内容
イベント検知	キャンペーンの条件となるイベントを検知します。
キャンペーン判定	検知されたイベントからキャンペーンを判定します。
ユーザー抽出	SQLでデータベースからキャンペーンの対象のユーザーIDを取得します。

イメージしやすい「お気に入り商品の値下げ通知」キャンペーンを例にします。

ある商品が値下げされると、データベースの商品テーブルの価格カラムが更新され、それをイベントとして配信システムにリクエストを送信します（イベント検知）。
配信システムはそのイベントの内容が「お気に入り商品の値下げ通知」キャンペーンの配信条件であることを判定し、キャンペーンの情報を生成します（キャンペーン判定）。
そのキャンペーン情報に含まれるセグメントのSQLを実行し、ユーザーIDを抽出します（ユーザー抽出）。

一連の流れで取得されたユーザーごとの情報は、JSONで最適化情報（Optimization Context）として後続の最適化処理に渡されて処理が移ります。

チャネル最適化

この処理でははじめに、キャンペーンごとに設定される「優先チャネル」でそのユーザーへの配信の可否をチェックし、可能であればその時点でチャネルが確定します。しかし、優先チャネルが未設定や配信不可の場合、配信候補のチャネルで配信実績のクリックログからユーザーの反応しやすさを判定してチャネルの優先度付けを行います。

channel_optimization

上記の最適化を経て、優先度は以下の4パターンのいずれかの値を元に算出します。

番号	処理内容
①	当該ユーザーの「キャンペーン×チャネル」のクリック率
②	当該ユーザーのキャンペーンのクリック率と、「キャンペーン×チャネル」の全ユーザーのクリック率
③	当該ユーザーの他キャンペーンでのチャネルのクリック率と、キャンペーン全体のクリック率
④	チャネルの全キャンペーンのクリック率で優先度計算

このように、基本的には配信対象ユーザーの配信実績やクリック率をもとに優先度を計算します。しかし、配信可否や配信実績の有無によっては、他のキャンペーン・チャネル・ユーザーのクリック率を利用します。

時間最適化

キャンペーンごとに設定される配信タイミングやチャネルの配信可能な時間帯などにもとづき、即時での配信、または指定時間での配信を予約します。配信予約の場合は、JBoss Data Grid（JDG）というインメモリの分散キャッシュデータストアに配信情報を保存し、指定の時間にそれを取り出して配信します。

www.redhat.com

また、時間以外の判定材料として「おまとめ配信」という機能があります。キャンペーンの配信条件によっては都度配信が過剰な配信数になりかねないものがあり、そうしたキャンペーンは一定時間内の配信内容を一通にまとめて配信します。先ほどの例の「お気に入り商品の値下げ通知」であれば、仮にわずかな時間差でお気に入り商品の値下げが連続してもまとめて配信されます。

timing_optimization

通数最適化

ここでは配信の重複と配信通数の上限をチェックをします。過去に同様の配信が済んでいたり、配信数が上限に達していたりした場合、配信をキャンセルすることにより過剰な配信を防ぎます。

チェック名	内容
チャネルの重複	同一キャンペーン・同一チャネルでの配信
コンテンツの重複	同一キャンペーン・同一コンテンツ（例えば「同じ商品の値引き通知」などの配信内容）」での配信
チャネルの通数上限	チャネル単位での通数上限

offering_number_checking

ここまでの最適化を経て配信処理に移ります。

最適化の改善

改めて今回の最適化の改善について説明します。

課題は、通数最適化の通数上限チェックが最適化全体のフローの最後に行われていたため、最適化チャネルが上限到達済みの場合に他のチャネルで配信されないことでした。そのため、この通数上限チェックを前倒ししてチャネル最適化の処理内で行うことにより、上限到達済みチャネルを最適化の対象から除外するように修正しました。

improved_optimization

具体的には、元々チャネル最適化で「配信対象ユーザーにとって利用可能」でなおかつ「優先度が高い」チャネルから優先度付けを行っていたところに、上限到達チャネルの除外処理を移行しました。

KPIの改善

改善の結果はKPIに現れました。

こちらはある特定のキャンペーンにおける配信チャネルの比率のグラフです。6/19のリリースを境にPushチャネル（緑色）の比率が増加しています。これはメールやLINEで上限到達済みの場合に、チャネル最適化でPushチャネルが選択されるようになったためです。

offering_channel_ratio:plain:h400

続いて、配信数の積み上げグラフではいずれのチャネルも配信数が増加しています。チャネル最適化の時点で上限到達済みチャネルが選択されず、次の優先チャネルでの配信が試行されるようになったためと見られます。

offering_by_channel

こちらは全キャンペーンにおける配信除外（最適化による配信のキャンセル）の除外理由ごとの積み上げグラフです。「通数上限（日）」（青色）と「通数上限（期間）」（赤色）が6/20以降減少しており、「チャネル利用不可（チャネル選択時）」（緑色）が増加しています。こちらも、それまでの通数上限による配信除外がチャネル最適化内の処理に吸収され、その次の優先チャネルでの配信が試行されるようになったためです。

excluded_status

このように、これまで最適化の機会を損なわれていたチャネルで配信数の増加する改善結果が見られました。売上損失のみならず、ユーザーの購入機会の損失を防いで利便性向上に繋がりました。また、この期間内では現れていませんが、ユーザーの利用チャネルの傾向の変化に合わせて優先順位が計算されるようになりました。結果、パーソナライズの精度が高まりました。