データ共有が推奨事項の品質に与える影響

こんにちは、Habr!



新しいクライアントをプラットフォームに接続するときは、統合の検証に特に注意を払い、プロセスの統合のステータスを常に監視します。 なぜこれが重要なのですか? データ収集は、品質の推奨事項を生成するための基礎であるためです。







推奨システムは、データ収集、ストレージ、処理、推奨の発行、成長ハッキングなど、いくつかの重要なコンポーネントに基づいています。 さらに、アルゴリズムとレイアウトプロセスの計算能力を提供する「鉄」。 したがって、アナリストの高価なチームは言うまでもなく、推奨事項の質に依存する少なくとも7ポイントを獲得します。 オンラインストアの推奨の外部サービスと内部システムの両方が、これらすべてのポイントをカバーし、すべての段階で質の高い作業を提供する必要があります。



アルゴリズムはブラックボックスと見なされており、オープンソースソフトウェアに基づく推奨システムの有効性の50〜70%を迅速に得ることができるという意見があります。 しかし、ソフトウェアは7つのポイントのうちの1つにすぎず、50〜70%の効率が得られる場合は1つのポイントにすぎません。 つまり 残りがなければ、これはシステムの効率の約7〜10%です。



何らかの方法で、私たちはロシア市場および事業を行っている他の国のほぼすべてのテクノロジー企業とコミュニケーションを取り、データ交換の品質を確保するためのアプローチは世界で最も考えられているものの1つであると確信しています。



長年にわたり、私たちはあらゆる点で膨大な専門知識を蓄積してきました。 アルゴリズムがもたらす結果と、グロースハッカーチームが店舗で達成している成功についてよく話しますが、今日は最初のポイントであるデータ収集に立ち止まりたいと思います。



収集段階で問題が発生した場合、それらは推奨事項の形成のさらなる段階に直接影響するため、オンラインストアが獲得できるほとんどすべての価値を破壊する可能性があります。 そのため、データの品質と完全性に高い要求を課しています。



私たちの実践では、内部プロセスの特性、技術的な障害、または単に不注意により、誤ったまたは不完全なデータが送信され、サービスの品質に悪影響を及ぼすさまざまなケースに遭遇しました。 たとえば、製品またはカテゴリのIDが週に数回変更される、製品が複製される、またはその逆で、すべてが転送されるわけではありませんなど。 このような要因は、推奨事項の精度に大きく影響します。



クライアントに当社の技術だけでなく、データ交換の品質管理などの専門知識も提供するため、データを推奨システムに転送する際に考慮する必要があるいくつかの重要なパラメーターについて説明します。



小売ロケットの統合



Retail Rocketシステムとの統合は、トラッキングコードのインストールによって実行されます。 サイトのさまざまなページに、特定のルールに従ってスクリプトが配置されます。 トラッキングコードを直接インストールするのに数時間かかります。 しかし、データの品質と完全性に対する高い要求により、プロセスが遅れる可能性があります。 たとえば、オンラインストアは、他のサービスの標準要件に従ってYMLファイルを準備し、推奨事項を作成するための重要な詳細を欠いています。 データ収集は今後のすべてのステップで非常に重要であるため、各統合ポイントを慎重に検討します。



トラッキングコードをインストールした直後に、当社の専門家がすべてのページのスクリプトの正確さ、および送信されたデータの品質と完全性をチェックします。 コードがすべてのページに配置されていない、すべてのイベントが追跡されていない(バスケットへの追加、注文)、またはすべての製品、そのプロパティおよびその他の重要なパラメーターがフィードで送信されていない状況があります。 私たちのチームにとって、これは、すべての段階で、トラッカーの正しいインストールとデータ転送がアカウントマネージャーからテクニカルサポートまで専門家によって監視されるプロセス全体です。

これは、すべてのクライアントが通過する統合かんばんボードの一部です。







統合チェックオプション



統合中に、多数のパラメーターをチェックします。 最も重要なことについて話します。



製品ベースの完全性



送信された商品とカテゴリの正確性と完全性、およびサイト上での商品とカテゴリの適合性は、推奨事項を形成するための最も重要なパラメータの1つです。

XMLフィードを介して送信される商品のカタログは、サイトメニューの構造と正確に一致する必要があります。 検証のために、マネージャはさまざまなカテゴリからいくつかのランダムな製品を選択し、製品がオンラインストアのWebサイトと同じネストされたカテゴリにあることを確認します。



構造に加えて、ファイル内の製品とカテゴリの数は、サイト上の製品の数に対応する必要があります。 特別なレポートの助けを借りて、サイトに投稿されたすべての製品がYMLファイルで転送されたかどうかを追跡できます。 フィードにない商品のリストは別のページに形成され、アカウントマネージャーはすぐにクライアントに送信できます。







さらに、在庫がなくなったアイテムをフィードから削除しないことが重要です。 在庫切れの製品では、コンテキスト広告、検索からのリンク、およびその他のリソースがつながる可能性があります。 在庫切れの製品ページにいるユーザーは、すでに需要を形成しています。 彼は購入する準備ができており、最も類似した代替品を推奨できます。 したがって、利用できない商品をフィードから削除するだけでなく、推奨アルゴリズムが代替商品の配送を形成できるように、最大​​パラメーターを転送することも重要です。



地域パラメータの検討



複数の都市に駐在員事務所があるオンラインストアの場合、各地域のデータを転送することが重要です。 地域によって商品の価格や在庫状況が異なる場合があるため、これらのデータを考慮してフィードで送信することが重要です。



さらに、これはマーケティングタスクにとって重要になる場合があります。たとえば、一部の都市では、割引は顧客にとってより重要であり、他の都市ではボーナスポイントが重要です。 地域性パラメーターを使用して、マーケティングキャンペーンを最適化できます。



製品のプロパティを渡す



推奨事項を定性的に形成するために送信する必要があるデータのもう1つの重要なパラメーターは、色、サイズ、ブランドなどの商品の特性です。



ここで注目すべき2つのポイント。 まず、一部の業界では、商品の特定の特性を考慮することは、適切な推奨を行うために重要です。 たとえば、靴屋の場合、このパラメーターはサイズになります。これは、36番ではなく40番のサイズの非常に類似したペアの推奨が購入者の関心を引く可能性が低いためです。 この問題を解決するため、2017年10月に、ファッションセグメントストアのパーソナライズメカニズムを改善し、推奨ブロック内のユーザーの服や靴のサイズを考慮しました。



第二に、店舗が各サイズと色を別々の製品と見なす場合、同じ製品の他のサイズ/色が類似製品の推奨に表示される場合があります。 たとえば、1つのサイズのリングの代わりに、まったく同じリングでサイズの異なる推奨事項が作成されます。 Retail Rocketプラットフォームでは、これはグループ製品を使用して解決されます。



製品IDまたはそのプロパティの変更



製品のIDまたはその他のプロパティが頻繁に変更される場合、たとえば製品がカテゴリ間で絶えず移動する場合、推奨事項の品質が著しく低下する可能性があります。 関連製品の推奨を計算する時点で、製品が1つのカテゴリにあり、推奨の要求時に別のカテゴリに既に移動していた場合-問題は関連性がない可能性があり、アルゴリズムが商品とカテゴリ間の関係を再形成するのに時間がかかります。



さらに、これは、たとえば、あるカテゴリの商品を別のカテゴリの商品に推奨しないという条件が規定されている場合など、ビジネスルール違反が原因で発生する可能性があります。 商品またはカテゴリのIDが変更されると、ビジネスルールが崩壊し、推奨事項が高品質で構築されるようにそれらを書き換える必要があります。



分析データの調整



データの完全性と転送の正確性を確認できるもう1つの重要な指標は、プラットフォームの販売レポートとクライアントのウェブ分析システム(Google Analyticsなど)の数値の一致です。 注文数と収益を比較します-違いは最小限でなければなりません。



したがって、すべてのトラッキングコードが正しく機能するかどうか、およびすべてのデータがシステムに正確に転送されるかどうかを理解します。 違いが見られる場合は、「掘り下げ」、理由を探し始めます。 たとえば、トラッキングコードが一部のページにインストールされていない可能性があり、そのためデータが異なる場合があります。 つまり、これは一種のマーカーであり、何かが間違っているかどうかをすぐに示します。



サイトとメールの同期



この項目はいくつかの理由で重要です。 まず、この同期のおかげで、特定のオンラインストアで電子メールのトリガーが効果的に機能することを理解しています。 たとえば、放棄されたブラウジングに関するメールを、ストアのメールを所有するユーザーに送信することは可能ですか?



また、トリガーメールのパフォーマンスも毎日監視しています。 チャートで、今日送信された電子メールの数が特定の期間の平均より少ないことがわかった場合、何が起こったかを確認します。



第二に、ユーザーに関する可能な限り多くの情報を受信するために、サイトとメールで彼のプロファイルを接続することが重要です。 トラッカーは、ユーザーがニュースレターの受信に同意できるすべてのページ(登録、ログイン、注文、サブスクリプションフォームなど)でアドレスを追跡し、最大数のクライアントのメールを収集できるようにします。 これにより、カバレッジ、出荷数が増加し、その結果、注文数が増加します。



さらに、ユーザーが手紙を開いてリンクをたどると、サイトでの行動、閲覧と購入の履歴を追跡できるため、サイトやメールニュースレターでより正確な推奨を行うことができます。



リアルタイム統合ステータスの追跡



アルゴリズムにおけるパーソナライゼーションプラットフォームの主な価値ですが、それらが最大限に機能するためには、とりわけ、サイトのすべてのページで正しい統合を常に監視する必要があります。



多くの場合、私たちの機能の1つは、インストール段階で作業を終了せず、すべてのメトリックを常に改善しようとすることです。 これはさまざまなアルゴリズムのA / Bテストだけでなく、推奨事項の正確性の継続的な追跡にも適用されます。



スペシャリストが統合の状態をリアルタイムで監視し、問題が発生した場合に迅速に対応できる特別なインターフェイスを開発しました







考えられる状況ごとに、必要なアクションの説明を含むレポートが自動的に生成され、オンラインストアの担当者に送信できます。



たとえば、オンラインストアのWebサイトから画像をダウンロードし、サイズを変更して独自のCDNに保存する別のサブシステムを開発しました。 統合ステータスでは、画像に問題があるかどうかを監視し、そのような画像の割合を確認し、システムによって自動的に生成された状況を修正するためのレポートとヒントをすぐにクライアントに送信できます。







クライアント側で技術的な障害が発生した場合、CDNに画像を保存すると、サイトやレターに推奨事項が表示されたままになります。



おわりに



外部サービスの品質がどれほど高くても、アルゴリズムがどれほど強力でスマートであっても、効果的なデータ交換がなければ、結果はオンラインストアが期待するよりも低くなる可能性があります。 統合に加えて、トラッキングコードがどこにでもインストールされておらず、YMLファイルに必要なデータが十分でない場合、時間がかかる場合があります。



データ交換の品質は外部サービスのパフォーマンスに直接影響しますが、すべてのサービスがそのような詳細の確認に十分な注意を払っているわけではありません。 私たちは、アルゴリズムを効率的かつ継続的に改善するだけでなく、クライアントのウェブサイトとの統合を監視しています。



All Articles