Entwicklung einer Affiliate-Marketing-Software für die Quints-Plattform

Es gibt viele Glücksspieleinrichtungen und iGaming-Unternehmen im Internet, die von Casinos bis hin zu Sportwetten reichen. Jeden Tag besuchen Tausende von Spielern diese Seiten, platzieren Wetten und führen andere Aktivitäten durch. Die Spieler kommen nicht von sich aus zu diesen Casinos und Wettbüros, sondern über Vermittler, die Links, meist über Banner im Internet, verbreiten.

Wenn sich ein Spieler über eine dritte Person oder Firma bei einem Casino anmeldet, dann wird ein bestimmter Prozentsatz der Ausgaben des Spielers an den Vermittler ausgezahlt. Quints wurde geschaffen, um Affiliate-Tracking-Lösungen für Glücksspielunternehmen anzubieten, damit diese ihre gesamte Palette an Informationen über die Spieler und die Personen, die sie eingeladen haben, verwalten können.

Es gibt drei Hauptteilnehmer der Glücksspiel-Affiliate-Statistikdienste von Quints:

• Kunden - Online-Casino-Vermittler, Wettbüros oder auch Online-Shops.
• Spieler - Die Personen, die in Online-Casinos spielen, Wetten bei Buchmachern platzieren oder Online-Einkäufe tätigen.
• Affiliates - Die Vermittler, die die Spieler zum Kunden bringen, hauptsächlich durch Werbeanzeigen. Die Kunden beauftragen verschiedene Affiliates, Spieler an sie zu vermitteln, und die Affiliates erhalten dafür eine Prämie.

Um jedoch Prämien an Affiliates auszahlen zu können, müssen die Kunden wissen, wie viele Spieler jeder der Affiliates eingebracht hat und wie viel diese Spieler letztendlich ausgegeben haben. Als Anbieter von Online-Glücksspielsoftware kommt hier Quints ins Spiel.

Quints ist die Ebene zwischen Kunden und Affiliates. Es handelt sich um ein System zum Sammeln von Statistiken zum Thema Affiliate-Marketing und zum Arbeiten mit diesen Daten unter Verwendung verschiedener Grafiken, Berichte usw. Quints wird sowohl von Kunden als auch von Partnern genutzt, es gibt also zwei verschiedene Arten von Kundenkonten.

Die ersten Schritte

Quints generiert einen speziellen Link für den Affiliate, den er in seine Werbeanzeigen einfügt. Wenn ein Spieler auf den Link klickt, wird er zunächst zu Quints weitergeleitet. Das System erfasst diese Daten und leitet sie an den Kunden weiter.

Wenn die Affiliate-Marketingplattform eine Reihe von Daten erhält, werden spezifische Formeln verwendet, um die Affiliate-Zahlungen für jeden Spieler zu berechnen. Quints ist also im Wesentlichen eine Art Aggregator oder Kalkulator für Spielstatistiken.

Die Eigentümer von Quints haben sich mit einem bereits entwickelten, zwei Jahre alten Produkt für Partnerberichte und Kundenmanagement an Evrone gewandt. Die Anwendung besaß ziemlich viele Altlasten, und etwa 70–80 % der Funktionalität waren bereits vorhanden. Während unserer gemeinsamen Arbeit an dem Projekt wurde jedoch vieles davon fertiggestellt und verbessert. Jetzt arbeitet unser Team an der Optimierung und Implementierung neuer Funktionen, um das Projekt zu etwas Besonderem zu machen.

Die Aufgabe

Die größte Herausforderung für Quints bestand darin, dass es sich nicht um ein einziges Projekt handelte, sondern um viele verschiedene Projekte mit jeweils eigenen Merkmalen für jeden Kunden. Der Kern des Projekts wurde entwickelt, aber wenn sich ein neuer Kunde angeschlossen hatte, wurde ein separater Fork für ihn erstellt. Und von diesem Fork wurde eine separate Anwendung für diesen speziellen Kunden bereitgestellt.

Einfach ausgedrückt, hatten wir für 10 Kunden 10 Abzweigungen vom Kern, die sich im Wesentlichen in 10 verschiedene Projekte verwandelten. Und in Zukunft wollte jeder der Kunden die Möglichkeit haben, seine individuellen Projekte selbst zu verbessern oder zu modifizieren. Das Ergebnis war, dass wir statt einem Projekt, das entwickelt und unterstützt werden musste, 10 Projekte erhielten, und diese Zahl sollte noch steigen, da Quints weiterhin neue Kunden gewann.

Das Deployment von neuen Funktionen stellte sich als sehr schwierig heraus, da sich alle Projekte minimal voneinander unterschieden. Und beim Deployment mussten diese spezifischen Unterschiede berücksichtigt werden. Die Aussichten für eine solche Architektur schienen überwältigend, da Quints neue Kunden gewinnen musste, aber jeder neue Kunde noch mehr Arbeit bedeutete.

Die Lösung

Als wir in das Projekt eingestiegen sind, haben wir als erstes den Ansatz für die Architektur angepasst. Wir haben begonnen (und tun es immer noch), uns auf ein einheitliches Projekt zuzubewegen. Wir wollten sicherstellen, dass alle Clients den gleichen Code haben und die Unterschiede nur in den Konfigurationen und Einstellungen liegen. Dies würde es uns ermöglichen, nur ein Projekt zu entwickeln und nicht für jeden Kunden ein eigenständiges.

Während der Laufzeit des Projekts kamen wir auch zu dem Schluss, dass eine Ebene zwischen dem Kunden und der Anwendung selbst gefehlt hat. Also haben wir einen Dienst geschaffen, der es den Kunden ermöglichte, uns Rohdaten zu senden, die wir mit Hilfe des DWH-Dienstes sammeln und im erforderlichen Format aufbereiten, damit Quints damit arbeiten kann. Dadurch mussten die Kunden auf ihrer Seite keine Zeit für die Aggregation aufwenden. Es handelt sich um einen Dienst mit hoher Last, der eine ziemlich große Datenmenge austauscht. Und nun funktioniert er einwandfrei.

Gemeinsam mit dem Team von Quints haben wir anschließend eine Dokumentation über die Arbeit des Projekts erstellt. Ursprünglich hatte die Anwendung überhaupt keine Dokumentation. Wir versuchen auch, alle Tests des Projekts auf den erforderlichen Stand zu bringen. Im Allgemeinen wird das Projekt einem intensiven Refactoring der Funktionalität unterzogen.

Technologiestack

Das Projekt ist nicht monolithisch und gliedert sich in Frontend und Backend. Das Backend ist in Ruby on Rails geschrieben, das Frontend in Angular.js. Das Frontend und das Backend sind separate Anwendungen, die über die vom Backend bereitgestellte API kommunizieren.

Infrastruktur und Tech-Stack:

• Infrastruktur: Kuber, DO, Prometheus (selbstgehostet), ELK (selbstgehostet), Amazon, CloudFlare
• Frontend: SPA (Single Page Application) auf Angular.js
• Backend: Ruby 2.3, Rails 4.2, Postgres 9.x, ClickHouse, Sidekiq Enterprise
• Zusätzlich: Gitlab (self-hosted), Jira, Confluence, Sentry (selbstgehostet), Mailgun, Testrail, Quints VPN

Anfangs wurde das Projekt über Capistrano auf Servern bereitgestellt, aber nach und nach haben wir uns davon wegbewegt, hin zu Docker und Docker-compose und später zu Kubernetes. Wir waren an strategischen Einstellungsentscheidungen beteiligt und haben eine eigene DevOps-Ausrichtung geschaffen.

Um den Zustand der Anwendung zu überwachen, verwenden wir:

• Sentry zur Überwachung von Ausnahmen in der Anwendung
• Grafana für die Überwachung von Server-Ressourcen

Darüber hinaus ist das Projekt stark von Gitflow abhängig. Für jeden Client wird ein Code-Zweig vom Hauptprojekt erstellt. Es wurde ein spezielles Skript geschrieben, das alle Änderungen aus dem Haupt-Repository durch Fork-Kinder holt. Dies ist jedoch ziemlich aufwändig, und wir versuchen, von einer solchen Implementierung wegzukommen.

Es wurden mehrfach DDoS-Attacken auf das Projekt verzeichnet. Also wurde das Rack-Attack-Gem hinzugefügt und gegen Throttling und Brute-Force-Passwörter konfiguriert. Es ist derzeit damit beschäftigt, DDoS-Attacken zu verhindern.

Wir implementieren momentan schrittweise neue Lösungen zur Optimierung des Kundenerlebnisses. Da die Berechnung der Daten in der Anwendung sowohl im Code als auch in den SQL-Abfragen verankert ist, betrifft die Optimierung beide Richtungen. Bei der Optimierung verwenden wir Standard-Tools, zum Beispiel RSpec-benchmark, RubyProf, StackProf und MemoryProfiler.

Unter Berücksichtigung des Datenimports vom Kunden haben wir die Interaktion mit verschiedenen Datenquellen implementiert. Standardmäßig hat die Anwendung mit SFTP gearbeitet, aber jetzt kann sie auch mit dem Google Cloud-Speicher arbeiten und Daten direkt von der Client-API abrufen.

Die größten Herausforderungen

Eines der Probleme, mit denen wir konfrontiert waren, war die falsche Berechnung von Statistiken, entweder aufgrund falscher Daten vom Kunden oder eines internen Problems in der Anwendung. Zum Beispiel hatte sich Ende des letzten Jahres die Aktivität bei einer Reihe von Teilprojekten deutlich erhöht. Sie war so stark gewachsen, dass die Anwendung mit den Berechnungen nicht mehr Schritt halten konnte. Wir mussten den Betrieb der Anwendung einen ganzen Tag lang überwachen und in Notfallsituationen die erhaltenen Informationen manuell auflösen.

Darüber hinaus hat Quints, wie wir bereits erwähnt haben, regelmäßig DDoS-Angriffe erlebt. Unsere DevOps und unsere Teamleitung haben diese Versuche, das Projekt zu kippen, jedoch schnell aufgelöst, und das Projekt ist seitdem ohne Ausfälle online. Wir sind auch auf ein Problem mit einem Hacker gestoßen, der sich im System registriert und begonnen hat, automatisch generierten Datenverkehr zu senden. Wir konnten das Problem allerdings schnell identifizieren und die Aktivität unterbinden.

Traffic-Verteilungssystem

Zu Beginn konnte der Rails-Monolith die Last von 600 RPS Werbetraffic (Klicks und Banneraufrufe) kaum bewältigen. Außerdem ist die Postgres-Datenbank gewachsen. Sie hatte Schwierigkeiten, mit großen Datenmengen umzugehen, und auch die Partitionierung hat in der Hinsicht wenig geholfen.

Einer der wichtigsten Firmenkunden von Quints hatte neue Anforderungen an Funktionalität und Belastung. Die neue Funktionalität sollte eine flexible Konfiguration der Traffic-Weiterleitung in Abhängigkeit von verschiedenen Routing-Regeln beinhalten. Je nach Region der Endbenutzer, die durch die IP-Anfrage, den Zeitraum der Werbekampagne und andere Einstellungen bestimmt wurde, war es beispielsweise notwendig, auf eine bestimmte Ressource umzuleiten. Deshalb haben wir uns entschieden, ein Traffic Distribution System (TDS) zu implementieren, das als Mittelmann dient, der Traffic zwischen Websites kauft und verkauft.

Wir wollten, dass das System einer Arbeitslast von mindestens 2000 RPS standhält, und haben uns entschieden, TDS als separates System außerhalb des Monolithen zu implementieren. Mehrere Architekturoptionen wurden von Grund auf neu entworfen, wobei einige Funktionen vom Monolithen auf das neue System übertragen wurden. Wir haben das TDS auf Basis einer Microservice-Architektur unter Verwendung des Microframeworks Roda (Ruby) implementiert. Für die Speicherung der rohen Trafficdaten über Klicks und Ansichten haben wir das Clickhouse DBMS verwendet, das in der Lage ist, große Datenmengen pro Datensatz zu verarbeiten und analytische Abfragen zur Datenaggregation blitzschnell durchzuführen. Kafka wurde integriert, um Daten an Clickhouse zu liefern. Kafka wurde auch verwendet, um aggregierte Daten an das monolithische Hauptsystem von Quints zu übertragen.

Wir haben also:

• eine TDS-Funktionalität implementiert
• die horizontale Skalierbarkeit jeder TDS-Komponente ermöglicht
• ermöglicht, der Last von 4000 RPS auf einem Knoten standzuhalten (wir können die Anzahl der Knoten weiter horizontal erhöhen, wodurch der Durchsatz des Systems steigt)
• einen Teil der Funktionalität aus dem Monolithen in ein neues System verschoben, das einfacher zu ändern, zu warten und zu erweitern ist
• die Belastung der Hauptmonolith-Anwendung reduziert
• die Belastung des Hauptspeichers von Postgres reduziert

Das Ergebnis

Neben der Entwicklung und dem Support des Systems selbst, waren wir auch an Folgendem beteiligt:

• einem Paket mit technischer Dokumentation für das Softwareprodukt
• Prozessen zur Vorhersage der Lieferzeit von Funktionen und Projektstarts
• am Prozess der Bewerbung und Einstellung neuer Mitarbeiter
• umfassenden Onboarding-Prozessen, einschließlich einer Roadmap für das Studium von Text- und Videodokumentation, Mentoring und Feedback
• Offboarding-Prozessen
• einem Prozess zur Erstellung monatlicher Berichte für Endkunden

Es wurde viel Zeit und Mühe in den Aufbau der Entwicklungs- und Interaktionsprozesse investiert. Gemeinsam mit Quints versuchen wir, die gemeinsame Nutzung von Fachwissen und Aufzeichnungen zu etablieren.

Bei dem Projekt wurden hervorragende Ergebnisse erzielt, und der Kunde war von unseren Beiträgen so beeindruckt, dass er beschloss, die Präsenz von Evrone in diesem Projekt zu erhöhen. Jetzt umfasst das Evrone-Team im Quints-Projekt 12 Backend-Entwickler, 3 QA-Ingenieure, einen Accountmanager und einen Projektmanager, der direkt an der Leitung des gesamten Projektteams beteiligt ist, welches mehr als 20 Experten umfasst.

Wenn Sie ein Affiliate-Geschäft automatisieren möchten oder mehr über die Verwendung eines Aggregators in der Verwaltung von Glücksspielunternehmen erfahren möchten, können Sie gerne über das untenstehende Formular Kontakt aufnehmen.