Die Erfahrung der Personalisierung eines Online-Shops am Beispiel einer dynamischen Empfehlung

Hallo Habr!

Ich werde meine Erfahrungen darüber teilen, wie wir unser eigenes Personalisierungssystem zusammenstellen, das auf dem „Wissen“ über einen potenziellen Käufer basiert.



Der einzige Unterschied zwischen unserer und den klassischen Lösungen bestand in der Verwendung eines kombinierten Bündels mehrerer Lösungen, die die Liste der Anforderungen erfüllten:

• Der Dienst sollte sofort auf N Standorten funktionieren
• dynamische Zielgruppensegmentierung
• Kollaborative Filterung für Prognosezwecke unter verschiedenen Bedingungen von Zielgruppensegmenten
• vorgenerierte statische Aufladung in Form von empfohlenem Inhalt + dynamischer Warenmix basierend auf Clickstream-Analyse
• Der Inhalt ändert sich fast in Echtzeit aus dem RAM unter Berücksichtigung dynamischer Koeffizienten

Dies ist detaillierter :) Und über den Rechen, der uns geholfen hat, den Stapel zum Besseren zu verändern.

Hintergrund

Es gibt eine Gruppe von Websites desselben Themas, deren Zielgruppe ähnlich ist - Websites einer Holding. Der Inhalt ist unterschiedlich. In der Regel veröffentlicht jede Website Informationen über die Waren, die die Holding produziert. Neben diesen "Content" -Seiten gibt es auch einen eigenen Online-Shop, in dem diese Produkte verkauft werden.

Jede Site hat ein eigenes Marketing-Team, eigene GA- und Ya-Metrik-Zähler. Bei der Analyse ihrer eigenen Zielgruppe haben andere Vermarkter den Inhalt der Website unter Berücksichtigung der Bedürfnisse der Besucher angepasst. Natürlich kreuzten sich die Zielgruppen dieser Websites, aber da es zu diesem Zeitpunkt keinen einzigen Zähler gab, waren die Ergebnisse der Analyse lokal.

Jeder Analyst wird die richtige Entscheidung treffen und mehr Daten zur Verfügung haben. Für diesen guten Zweck entwickelte er seine eigene Version der Theke.

Warum nicht Google Analytics?

Sampling, das Fehlen der Fähigkeit, alles über den Benutzer mit seiner Kette von Bewegungen von der externen Site über eine Reihe unserer Sites mit Details, die er beobachtet hat, usw. abzurufen. Ja, in Bezug auf GA-Aufgaben ist es ein gutes Tool, aber wenn Sie Daten in Echtzeit abrufen und sofort entscheiden möchten, welche Inhalte dem Besucher angezeigt werden sollen, dann ... hat der Analytics-Riese keine solche Lösung. Tanzen mit Tamburinen der Kunden-ID für die Übertragung zwischen Standorten ist nicht unsere Option.
Das Setzen eines einzigen Zählers für alle Websites ist keine völlig korrekte „politische“ Entscheidung, und sie würden sofort in die Einschränkung der kostenlosen Version fallen.

Ich muss sofort sagen, dass ich das Rad nicht neu erfunden und mich auf eine bescheidene Funktion beschränkt habe, deren Aufgaben waren:

1. Korrigieren Sie jeden einzelnen Benutzer, unabhängig davon, auf welcher Site sich die Gruppe befindet. Dies war notwendig, um ein einzelnes Kundenprofil zu erstellen, in das alle seine Daten mit Bezug auf jede Site geschrieben wurden.
2. Verfolgen einer langen Kette von Übergängen zwischen allen Standorten einer Gruppe innerhalb einer Sitzung. Dies war notwendig, um Folgendes zu ermitteln: die Interessen der Benutzer; was sie sahen; was sie gekauft haben; was in den Korb gelegt, aber nicht gekauft wurde; Welche Produkte von verschiedenen Standorten können während des Kaufprozesses „Ersatzprodukte“ sein?
3. Verfolgung der Werbeaktivitäten aller Vermarkter (in jedem Team der Website) zur anschließenden Analyse. Dies war notwendig, um: das Profil jedes Besuchers zu bereichern; Identifizierung optimaler Werbekampagnen, die an das Produkt gebunden sind; Identifizierung effektiver Werbekanäle in Bezug auf ein Produkt oder eine Kampagne usw. Die Liste ist sehr lang.

Alle Daten wurden in Echtzeit in die lokale Sammlung eingespeist. Es stellte sich nicht sehr schlecht heraus. In Zukunft war es möglich, aggregierte Berichte sowohl nach Produkt als auch nach Publikum, Werbekampagnen, Verkehrsquellen und allem, was mir in den Sinn kam, zu erstellen. Für jede Wareneinheit gab es Daten zu Preisen, Lagerbeständen, Rabatten, Werbeaktionen und sogar ein Meer von Daten.

Lob die Situation, ich bin Analyst + Entwickler + Vermarkter + Manager + Ich hatte Zugriff auf alles, was in der Holding digitalisiert wurde. Ich hatte zu Beginn keine technische Aufgabe, sondern habe es für mich selbst getan, um normale Datenanalyseaufgaben zu lösen.

Technischer Moment:

• MongoDB wurde als einheitliches Speichersystem verwendet
• Javascript-basierte Echtzeit-Datenerfassung
• lokaler Datenaustausch zwischen Standorten basierend auf rabbmmq

Während alles, wie alle anderen ... Aber dann fing es an

Angesichts der Tatsache, dass sich das Wissen über Käufer und Produkte ausreichend angesammelt hat, haben wir beschlossen, ein eigenes Empfehlungssystem für den Online-Shop zu erstellen.

Alles ist großartig geworden. Wir haben alles analysiert, aber ohne Fanatismus. Das Modell wurde größer und wie gewöhnlich kam die Zeit, als ich mehr wollte.

Technischer Moment 2:

• Die MongoDB-Replikation half beim Leben, aber das Sharding wurde sofort abgebrochen. Dieser Moment hat einige interne Aspekte nicht weitergegeben. Wenn die Clickstream-Sammlung über Shards verteilt sein könnte, ist die Sammlung von Benutzerprofilen nicht mehr vorhanden. Es war möglich, die Ergebnisse aggregierter Abfragen von verschiedenen Shards für einen Teil der Berichte zu sammeln, aber die Ausführungsgeschwindigkeit ließ zu wünschen übrig. Ohne Scherben funktionierte es besser und stabiler
• Echtzeit-Datenerfassung basierend auf Javascript - hier war das CORS + HTTPS-Bundle ein Diktator. Als ein Benutzer zu einer der Websites der Gruppe kam und unser Service ihn sofort in der Multi-Domain-Zone "autorisierte" (ich erinnere mich, dass es zu diesem Zeitpunkt 5 unabhängige separate Websites gab), war dies für andere Vermarkter, die jetzt alle sehen konnten, technologisch schön und mysteriös Treffer-Kette für alle Standorte gleichzeitig.
• Das Modell des Empfehlungsdienstes wurde in Python geschrieben. Aber das Training hat lange gedauert. Die Modelldatei hat mehrere zehn GB.
• Der Empfehlungsdienst arbeitete standardmäßig mit seiner eigenen API, aber die Antwort des Servers wurde zu einem Engpass oder vielmehr zu der Zeit, die benötigt wurde, um das Ergebnis zu erhalten. Je mehr Daten, je größer das Modell, desto größer das Modell, desto langsamer wird das Ergebnis erzeugt. Als Reaktion darauf mussten viele Faktoren berücksichtigt werden, die sich stündlich änderten (Lagerbestände an Waren, Benutzereigenschaften und Mode, alle Arten von Rabatten usw.).

Einige Monate später hat die Qualität der API alle vernünftigen Grenzen der "Qualität" überschritten. Für Benutzer hat die Antwortgeschwindigkeit die 400-ms-Marke überschritten. Inhaltsblöcke sammelten sich langsam, die Website wurde merklich langweilig. Die MongoDB-Sammlungen beliefen sich auf zig Millionen Datensätze ...

Es ist Zeit, etwas zu ändern

Fast alle Instrumente wurden auf der Ebene der Operationen protokolliert, jedes Niesen wurde gemessen.

Was hat sich für was geändert:

• Clickhouse auf MongoDB
• weiter MongoDB zu MongoDB + Tarantool
• EVE auf Flasche
• Weitere Flasche auf Falcon
• Eine separate Datei war mit Versprechungen in js und mit Benutzerberechtigung für alle Domänen. Sie haben die Logik nicht geändert und das Refactoring gewonnen

Warum nicht Metric API?

Zuerst habe ich nur nach vorgefertigten Lösungen von Yandex gesucht, aber es dauerte nicht lange. Dies ist gut, wenn eine Site in Betrieb ist. und wenn es n gibt und Sie die Daten sofort verarbeiten möchten, haben Sie keine Zeit, mit Tamburinen zu tanzen.

Warum MongoDB?

Es wurden ständig Produktspezifikationen hinzugefügt, von denen einige leider nicht immer präsentiert wurden.
Verwendung aggregierter Abfragen - passt sehr gut in das Format des lokalen technologischen Stils des Teams. Klassisches SQL wollte keine Tabellen erstellen.

Sehr oft wurden die Arten und Varianten von Daten, die gespeichert und verarbeitet wurden, geändert.
Zuerst dachte ich, ich würde Yandex Clickhouse als Basis für den Service verwenden, aber dann gab ich diese Idee auf, aber Clickhouse war auch in unserem Stapelhalter.

Es ist eine neue Zeit gekommen, 2000 Anfragen pro Sekunde ... vorausgesetzt, dass in einer Woche neue Funktionen eingeführt werden und die Last noch weiter zunimmt.

Während des maschinellen Lernens sah ich zum ersten Mal in htop eine 100% ige Auslastung von 12 Kernen gleichzeitig und einen vollständigen Austausch auf einem produktiven Server. Zabbix teilte aktiv mit, dass MongoDB bereits zweimal innerhalb von 10 Minuten den Master in der Replik gewechselt hatte. Jeder wollte Stabilität und einen vorhersehbaren Zustand.

Es ist Zeit, etwas 2.0 zu ändern

Die Anzahl der Benutzer hat zugenommen. Die Anzahl der Kunden ist ähnlich. Für alle, die jemals auf einer der Websites waren, haben wir ein persönliches Profil erstellt. Das Publikum der regelmäßigen Besucher war teilweise gebildet.

Was wussten Sie zu tun? Ja, alle nicht standardmäßigen Berichte für Analytics + Content Diversity:

• Wählen Sie alle Benutzer aus, die aus der Werbekampagne A im letzten Quartal stammten, und finden Sie diejenigen, die an Waren aus Position N interessiert waren. Schließen Sie dann diejenigen aus, die nur auf Lager gekauft haben, schließen Sie diejenigen aus, die ein Produkt in den Warenkorb gelegt und verlassen haben Website. Führen Sie eine Sortierung in absteigender Reihenfolge des Einkommens des Geschäfts durch, wenn diese Benutzer nun auf die Website des Geschäfts gekommen sind und Z-Waren gekauft haben. So etwas und mit anderen Perlmuttknöpfen ...
• Um den eingehenden Datenverkehr zu analysieren, müssen Benutzer mit dem utm-Tag Y ein Inhaltsangebot erstellen, aber VOR dem Build den Benutzer identifizieren, diejenigen ausschließen, die sich letzte Woche auf Site S (einer der Gruppen von Holding-Sites) befanden und an Produkt Q interessiert waren - für solche Generieren von Inhalten, sortiert nach x-, y- und z-Kriterien
• Es ist trivial, diejenigen zu finden, die häufig Site A besuchen, manchmal auf Site B (sie haben einen bestimmten Abschnitt besucht) und die im Online-Shop einen durchschnittlichen Scheck von mehr als N Rubel haben

Tatsächlich hatte dies nicht das Format "abnorme Programmierung", ich wollte etwas anderes. Ein anderer kam zu uns. Zum Zeitpunkt der Werbekampagnen war der Online-Shop von der Last gebeugt, was können wir über unseren API-shki sagen, der diese Ladung „daneben stehend“ auffing.

Entscheidungen rechtzeitig getroffen

Wir haben eine Analyse des Publikums durchgeführt und beschlossen, Inhalte nicht für alle, sondern für Besuchergruppen zu sammeln. Die ganze Menge war gebündelt. Jeder Cluster hatte seine eigenen Eigenschaften und seinen eigenen Geschmack für das Einkaufen. Clustering wird jeden Tag durchgeführt. Dies ist notwendig, damit der Benutzer zum Zeitpunkt des nächsten Besuchs genau den Inhalt anzeigt, der ihm am meisten entspricht.

Von Sitzung zu Sitzung ändern sich die Interessen und Bedürfnisse des Kunden. Wenn er das letzte Mal automatisch dem Cluster Nr. 788897 zugewiesen wurde und dann seine aktuellen Interessen berücksichtigt, kann das System diese auf den Cluster Nr. 9464 übertragen, was sich effektiver auf die nachfolgende Konvertierung auswirkt.

Nach dem täglichen Clustering-Verfahren wurde die nächste Phase eingeleitet - Modellschulung, bei der neue Daten und Kenntnisse über Kunden berücksichtigt und Waren berücksichtigt wurden, die in den Verkaufsregalen erschienen oder für immer zurückblieben.

Für jeden Cluster haben wir im Voraus Inhaltsblöcke gebildet und diese im Speicher aufgezeichnet. Dann kam Tarantool in seiner ganzen Pracht auf die Bühne. Zuvor haben wir damit schnelle Daten gespeichert, die dann beim maschinellen Lernen verwendet wurden. Dies war die beste Lösung, um MongoDB, das bereits mit anderen Aufgaben beschäftigt war, nicht zu rasseln. Im Weltraum speicherte Tarantool Daten zu Waren, Benutzerdaten (notwendiges Wissen über den Käufer).

Grob gesagt haben wir heute Abend Inhalte für jede Gruppe von Zielgruppen „vorbereitet“, die die Website morgen besuchen könnten. Der Benutzer kam herein, wir stellten schnell fest, ob wir etwas über ihn wussten, und wenn die Antwort ja war, würde das erforderliche Inhaltspaket zu Nginx fliegen. Für NoName-Benutzer wurde separat ein Standardcluster mit seinem Inhalt zusammengestellt.

Nachbearbeitung zur Personalisierung

Wir wussten, dass es einfache Benutzer gibt, und es gibt solche, für die wir eine ganze Wissensdatei haben. All dieses Zeug war in Tarantool und wurde in Echtzeit aktualisiert.

Zum Zeitpunkt der Zusammenstellung der Seite kannten wir die gesamte Geschichte der Einkäufe und verlassenen Körbe jedes Besuchers (wenn er zuvor unser Kunde gewesen war), bestimmten seine Clusterzugehörigkeit, das Clickstream-Modul gab Wissen über die Quelle des Verkehrs, wir wussten über seine Vergangenheit und seine unmittelbaren Interessen Bescheid. Wir haben ein TOP50-Array im laufenden Betrieb aus zuvor angesehenen Produkten (auf einer der Websites der Gruppe) erstellt, die Mode „bestimmt“ und den „Geschmack“ -Gehalt dieser Produkte gemischt, deren Themen im TOP50 am häufigsten Phylum sind. Diese einfache Analyse der zuletzt angesehenen Produkte ergab einen echten Gewinn. Cluster-Inhalte haben wir personalisiert bereichert.

Ergebnis unserer Erfahrung

1. Wir haben den Prozess der Erstellung persönlicher Inhalte N-mal beschleunigt
2. Reduzierte Serverlast um das 15-fache
3. Wir können fast jeden Inhalt persönlich erstellen, unter Berücksichtigung vieler Wunschliste-Vermarkter, Merkmale der Produktpräsentation und vieler Ausnahmen, unter Berücksichtigung von Daten aus dem Benutzerprofil und Ereignissen, die derzeit auf der Website stattfinden - und das alles für ca. 25 ms
4. Die Conversion für solche Blöcke fällt nicht unter 5,6% - Benutzer sind bereit, das zu kaufen, was ihren Anforderungen derzeit näher kommt
5. Die Seitenladegeschwindigkeit ist ideal - sie haben den Inhalt, der "hinter" dem Cluster war, um> 67% entfernt, was korrekt ist
6. Wir haben ein Tool, das gemäß den Aufgaben der Vermarkter nicht nur die Antwort „Was früher passiert ist“ gibt, sondern auch dazu beiträgt, Inhalte in naher Zukunft fragmentiert zu formulieren und dabei die Interessen und Bedürfnisse potenzieller Käufer zu berücksichtigen
7. Informationen von DMP wurden dem Profil jedes Käufers hinzugefügt. Jetzt können wir Clustering durchführen, einschließlich nach sozialen Netzwerken, Interessen, Einkommensniveau und anderen Süßigkeiten
8. Unser Empfehlungsservice ist besser geworden, mehr Bestellungen im Laden

Was nützt das?

Wir haben neue Erfahrungen gesammelt, eine Reihe von Hypothesen getestet, die wir vorher nicht angehen konnten. Wir verwenden keine kostenpflichtigen Lösungen von Drittanbietern für einen Empfehlungsservice, der nicht alle unsere Funktionen berücksichtigt und auf derselben Domain arbeitet. Das Team erhielt einen guten und interessanten Fall, den es erfolgreich bewältigte.

Der Appetit wächst ... jetzt testen wir eine neue Logik der Inhaltszusammenstellung. Wir möchten Seiten für Werbekampagnen, Newsletter und andere externe Aktivitäten sammeln. Die Pläne beinhalten das Übertragen der Konfigurationslogik vom Manul-Modus in die Richtung des maschinellen Lernens. Websites werden ihr eigenes Leben führen, und wir werden, abgesehen von „Popcorn“, die Entwicklung der Präsentation von Website-Inhalten auf der Grundlage der Meinung von AI beobachten.