Fallstudie: E-Commerce-System für Yijinxiang – Bildeffizienz, Mitgliederverwaltung und Marketing-Backend

Hintergrund der Probleme

Etablierte Lebensmittelmarken benötigen nicht nur eine Präsentationsseite, sondern ein umfassendes E-Commerce-System, das die Verwaltung von Produkten, Mitgliedern, Marketingaktionen und Inhalten ermöglicht. Die Herausforderungen bestehen hierbei in zwei Punkten: Erstens ist die große Anzahl an Produkt- und Aktionsbildern, die eine umfassende Bildverarbeitung erfordern, um die maximale Inhaltserstellung (LCP) nicht zu beeinträchtigen. Zweitens sind die Marketingregeln komplex – mehrere Aktionen gleichzeitig, Mitglieder-basierte Rabatte, die Kombination von Gutscheinen – Wenn diese Regeln fest in den Code geschrieben werden, müssen für jede neue Aktion die Entwickler die Änderungen implementieren, was den Betriebsprozess an die Entwicklungszeiten bindet.

Methodische Vorgehensweise

• —Aufbau eines E-Commerce-Kern mit Next.js, GraphQL, PostgreSQL und Redis: Die Frontend-Anwendung erhält über GraphQL Produkt-, Mitglieder- und Marketingdaten, die jeweils modelliert werden. Redis speichert häufige Abfragen, um die Datenbanklast zu reduzieren.
• —Priorisierung der Bildverarbeitung: Die hochgeladenen Originalbilder werden beim Ausgeben in moderne Formate konvertiert und in verschiedenen Größen für verschiedene Bereiche zugeschnitten. Das Frontend lädt die entsprechenden Versionen basierend auf dem Gerät, anstatt die Originalbilder direkt an den Browser zur Vergrößerung zu übergeben.
• —Überprüfung der LCP-Ressourcen-Ladekette: Überprüfung der Priorität der Lade des Hauptbildes auf der Startseite, der Vorab- und Größenangaben. Das Ziel ist, die LCP innerhalb von 2.5 Sekunden zu erreichen und während der Auslieferung zu überprüfen.
• —Zentralisierte Marketingregeln: Die 19 verschiedenen Arten von Marketingaktionen (Mindestbestellwert, Mindestanzahl, Geschenke, zeitlich begrenzte Rabatte usw.) und die 5 verschiedenen Mitgliederstufen werden in ein kombinierbares Regelmodell umgewandelt. Die Marketing-Mitarbeiter können die Bedingungen und Zeiträume im Backend festlegen, während das Frontend während des Kaufs die Berechnungen basierend auf den Regeln durchführt – Neue Aktionen müssen nicht im Code geändert werden.

Verantwortungsbereich von Falcon

• E-Commerce-Frontend, Produkt- und Inhaltsseiten
• Regeln für die Verwaltung von Mitgliedern, Aktivitäten und Gutscheinen
• Integration von GraphQL API, Datenbank und Cache
• Optimierung der Bildausgabe und der Haupt-Ladepfade

Datenfluss für den Einkauf und den Betrieb

1. 01Kunden gelangen über Produkt- oder Aktionsseiten zum Kaufprozess. Die Bilder auf den Seiten werden auf die entsprechenden Größen für das jeweilige Gerät optimiert.
2. 02Das Frontend erhält über GraphQL die benötigten Daten für Produkte, Mitglieder und Marketingaktionen. Häufige Abfragen werden über Redis bereitgestellt.
3. 03Im Checkout berechnet das Backend den endgültigen Preis basierend auf der Mitgliederstufe, den laufenden Aktionen und den Gutscheinregeln. Wenn mehrere Regeln gleichzeitig zutreffen, werden sie in einer bestimmten Reihenfolge verarbeitet, ohne dass der Preis auf der Frontend-Seite berechnet wird.
4. 04Marketing-Mitarbeiter verwalten Produkt-, Inhalts- und Aktionszeitpläne im Backend. Änderungen an den Regeln erfordern keine Änderungen oder Neuentwicklungen im Code.

Einschränkungen, Fehlerbehandlung und Alternativen

• —Die Zahlen zur Bildoptimierung beschreiben lediglich die Unterschiede in den technischen Assets und führen nicht zu einem Umsatzwachstum.
• —Die Leistung kann je nach Seite, Bildern, Geräten, Netzwerk und Drittanbieter-Diensten variieren und sollte nicht als fester Wert betrachtet werden.
• —Die Anzahl der Mitglieder und Funktionen repräsentiert den Umfang des Systems, entspricht aber nicht der tatsächlichen Nutzung oder dem Umsatz.
• —Der Umsatz wird immer von der Backend-Seite berechnet, die Frontend-Anzeige dient lediglich der Information und soll Inkonsistenzen während Änderungen der Regeln vermeiden.

Wie Beweise überprüft werden

• ✓Marken, Produkte und die Haupt-Shopping-Oberfläche können auf öffentlich zugänglichen Websites überprüft werden.
• ✓88.8% ist ein Vergleich der Gesamtgröße der optimierten Bilder, handelt sich um eine einmalige technische Messung. Das Messobjekt sind die Bildressourcen selbst, nicht um kontinuierliche Überwachungsdaten.
• ✓Die LCP-Ziele und die Funktionsgröße stammen aus öffentlich zugänglichen Dokumenten.
• ✓Es liegen keine öffentlich zugänglichen GA4-, GSC-, Konversions- oder Umsatzdaten vor.

Verfügbare Messwerte und Fähigkeiten