Die im Mai dieses Jahres in Kraft getretene DSGVO hat den Internet-Marketing-Markt ernsthaft beeinträchtigt. Die Teilnehmer möchten die genaueste Zielgruppe für die Anzeige von Anzeigen bilden. Dafür ist es jedoch erforderlich, die ausdrückliche Zustimmung des Nutzers einzuholen. Andernfalls kann selbst eine kleine Nischenressource mit mehreren Millionen Bußgeldern belegt werden. Einige Ressourcen wurden geschlossen, aber viele werden konvertiert, um neuen Anforderungen gerecht zu werden. Ein gutes Beispiel dafür ist unser Projekt eines Werbekampagnen-Management-Service für einen Kunden aus den USA.
Über den Service
Unser Kunde, ein amerikanisches Unternehmen aus Los Angeles, konzentriert sich auf das Marketing in der Musikindustrie. Der Service bietet Unterstützung für komplexe Werbekampagnen für Teams unterschiedlicher Größe - von Banden um die Ecke bis zu den Stars der Weltbühne.
Im Wesentlichen handelt es sich bei unserem Kundenservice um ein Startup, das eine spezialisierte Marketingplattform entwickelt, mit der Investitionen von Plattenfirmen gesammelt werden können, da die Besonderheiten des Publikumsverhaltens in einer bestimmten Branche berücksichtigt werden. Mit der Plattform können Sie Anzeigen gezielt schalten, indem Sie das Verhalten von Nutzern analysieren, die einmal Interesse an einem bestimmten Team gezeigt haben. Die Hauptnutzer der Ressource sind Musiker und Industriearbeiter (Manager, Mitarbeiter von Plattenfirmen, Konzertveranstalter und viele andere).
Zu Beginn unseres Projekts funktionierte der Service bereits und konnte sich eine bestimmte Position auf dem Markt sichern. Es war jedoch eher ein Prototyp, der die Grundhypothese eines Unternehmens testete, zumal ein Teil der Funktionalität über Partnerdienste implementiert wurde. Wir haben uns mit der Entwicklung verbunden, um eine vollwertige Architektur zu schaffen, und die DSGVO war der eigentliche Anstoß, der alle Transformationen auslöste. Unsere Aufgabe war es nicht nur, den bestehenden Dienst zu aktualisieren, sondern ihn mit der neuen Gesetzgebung neu zu erstellen, zu aktualisieren und eine einheitlichere Benutzeroberfläche zu schaffen.
Implementierung
Das gesamte Projekt war in mehrere Phasen unterteilt.
In der ersten Phase haben wir den Teil, der zuvor in PHP - Link Shortener und Authorization Service funktioniert hatte, von Grund auf neu geschrieben.
Link Shortener ist ein Teil der Funktionalität, die allen registrierten Benutzern kostenlos zur Verfügung steht und dazu dient, Kunden für die kostenpflichtigen Dienste des Unternehmens zu gewinnen. Mit diesem Dienst können Sie einen langen Link zu einem kurzen Formular erstellen, um ihn in sozialen Netzwerken zu veröffentlichen. Gleichzeitig können Sie den Link anpassen, indem Sie beispielsweise Geo-Targeting festlegen: Je nach Land, aus dem der Benutzer stammt, können ihm verschiedene Zielseiten angezeigt werden.
Bei der Aktualisierung des Backends haben wir OpenJDK 1.8, Kotlin und Spring boot / data / web verwendet - das Standard-Framework für ein Projekt, das keine hohen Lasten erwartet. Übrigens haben wir in diesem Projekt Kotlin zum ersten Mal „im Kampf“ ausprobiert, und aufgrund seiner Syntax konnten wir die Entwicklung erheblich beschleunigen. Auf jeden Fall werden wir es in anderen Projekten verwenden.
Die in der ersten Phase implementierte Datenbank des Autorisierungsdienstes und des Kürzers basiert auf PostgreSQL - das relationale Datenspeichermodell war zur Lösung dieser Probleme gut geeignet.
In der zweiten Phase haben wir das Management von Werbekampagnen übernommen. Diese Funktionalität auf der Client-Plattform gab es auch schon früher, jedoch über den Service des Partners, für den Sie bezahlen mussten. Jetzt ist die Plattform des Kunden so weit gewachsen, dass die Infrastruktur gepflegt werden musste. Im Gegensatz zu Drittanbietern ist es viel einfacher, den eigenen Service in die richtige Richtung zu entwickeln und schnell die erforderlichen Änderungen vorzunehmen.
In diesem Teil des Projekts haben wir nur die externe API für den Kampagnenmanager implementiert. In der dritten Phase haben wir dieses Modul entwickelt - wir haben die API fertiggestellt und eine vollwertige Benutzeroberfläche für den Kampagnenmanager erstellt.
Parallel dazu haben wir eine kleine proprietäre DMP (Data Management Platform) entwickelt, die die Erfassung von Besucherdaten verwaltet. DMP-Daten werden in MongoDB gespeichert, da wir uns entschlossen haben, die Grundlagen für die zukünftige horizontale Skalierung dieser Datenbank zu verlassen. Jetzt bedient DMP bis zu zweitausend Anfragen pro Sekunde (in Spitzen), während wir uns darauf konzentrierten, etwa ein Terabyte Daten zu speichern. Ein solches Volume hätte in PostgreSQL gespeichert werden können, aber auf lange Sicht wäre es notwendig gewesen, große Anstrengungen zur Skalierung zu unternehmen.
Dieselbe MongoDB wird in der Kampagnenmanager-Datenbank (Campaign DB) verwendet - hier hat uns das Modell einer dokumentenorientierten Datenbank gut angesprochen. Kampagnen werden als einzelne Einheiten ausgeführt und können erweitert werden.
Alle Caches funktionieren auf Redis.
Frontend: Angular 5, TypeScript, HTML5, Sass, Node.js, npm, Angular CLI.
In der letzten Phase des Projekts haben wir die Integration von Client-Systemen und den Service eines wichtigen Partners abgeschlossen, wodurch dem Unternehmen der Zugang zu einer riesigen Anzahl von Musikern ermöglicht wird, wodurch die Anzahl der Benutzer erhöht wird.
Es gab einige Schwierigkeiten im Projekt. Der Kunde wollte Benutzerdaten und Registrierungen speichern, die während des Betriebs des Dienstes gesammelt wurden, während das Modell geringfügig geändert wurde. Parallel zur Änderung der Architektur haben wir Registrierungen übertragen und deren Prinzipien geändert - vom Benutzernamen zur E-Mail als Login, was uns aufgrund der begrenzten Anzahl von Benutzern mit derselben E-Mail-Adresse viele schlaflose Nächte bescherte. Das Modell der Rechte im System hat sich geändert. Früher arbeitete der Dienst nach einem zweistufigen Modell, aber wir haben ein Modell von Rechten ohne Einschränkungen implementiert (einschließlich der Möglichkeit, eingeschränkte Rechte zu erteilen).
Gleichzeitig wurde die Funktionalität erweitert. Beispielsweise wurde in einer der Phasen Multistore angezeigt, mit deren Hilfe Endbesucher, die auf kurze Links zu einer bestimmten Komposition klicken, Seiten mit einer Liste von Diensten einrichten können, bei denen diese Kompositionen zum legalen Kauf oder zum Abhören verfügbar sind.
Es lohnt sich, separat über die DSGVO zu sprechen
Der Hauptmarkt unseres Kunden sind die USA, aber etwa 10% des Verkehrs, den das Unternehmen nicht verlieren wollte, stammte aus Europa. Seit Inkrafttreten der neuen Verordnung (25. Mai 2018) wurde ihre Ausrichtung einfach deaktiviert. Nach Rücksprache mit Anwälten haben wir den Service so aufgebaut, dass er nicht der DSGVO widersprach, und ab dem 16. August haben wir erneut mit dem Targeting begonnen.
Ehrlich gesagt haben wir die Feinheiten der Vorschriften in der gesamten Gruppe von zwei Wochen untersucht. Die Schwierigkeit in dieser Phase bestand darin, dass es angesichts der allgemeinen Unschärfe der Formulierungen bisher keine Strafverfolgungspraxis gibt - reale Fälle, die zeigen könnten, wie man es richtig und wie man es falsch macht. Jetzt (nach eigenen Recherchen und Konsultationen mit Anwälten) sind wir jedoch von der implementierten Architektur der Lösung überzeugt.
Die Logik des Dienstes beinhaltete das Hinzufügen eines Benutzers, der einem kurzen Link zu einer bestimmten Zielgruppe folgt, damit ihm später Anzeigen gezeigt werden können. In Bezug auf die DSGVO kann dies nicht ohne die ausdrückliche Zustimmung des Benutzers erfolgen. Und wir haben eine Einverständniserklärung implementiert. Wenn Sie auf den Link unten auf der Seite klicken, wird ein Schild mit einer Frage und zwei Schaltflächen angezeigt. Die Anfrage wird für Benutzer geöffnet, deren IP zu Europa gehört, und ihre Antwort wird in Form von Cookies gespeichert, sodass Besucher nicht jedes Mal Tasten drücken müssen.
Wenn es keine Benutzereinwilligung gibt (d. H. Cookies), zeigen wir einfach kein Pixel an, d. H. In der allgemeinen Statistik des Dienstes wird die Tatsache des Besuchs gezählt, Benutzerdaten werden jedoch nicht erfasst und berücksichtigt.
Die DSGVO legt architektonische Einschränkungen fest - personenbezogene Daten müssen nicht nur korrekt erfasst, sondern auch sicher gespeichert werden. In unserem Fall gelten diese Einschränkungen für das implementierte DMP (trotz der Tatsache, dass anonyme Daten mit anonymen Kennungen gespeichert werden, die nur eine hypothetische Dekononymisierung ermöglichen) und die Datenbank des Autorisierungsdienstes. In unserer Architektur sind diese Basen eindeutig in separaten Blöcken zugeordnet. In Übereinstimmung mit den Vorschriften ist der Zugriff Dritter auf diese „sensiblen“ Module natürlich eingeschränkt.
Nur der entsprechende Dienst hat Zugriff auf die Autorisierungsdatenbank. Alle anderen Dienste wissen nichts über die persönlichen Daten des Plattformbenutzers - sie müssen nur vom Autorisierungsdienst validiert werden.
Die DMP-Datenbank enthält auch nur den gleichnamigen Dienst. Gleichzeitig werden nur Aggregate von Zielgruppendaten aus der Datenbank zurückgegeben, nicht jedoch die Daten selbst. Diese Aggregate bilden die Grundlage für die Analysen, die Benutzer des Dienstes aus der Musikbranche in ihrem persönlichen Konto erhalten.
Wir haben auch ein obligatorisches Verfahren zum Hochladen und Löschen von Benutzerdaten. Es gab eine Frage, wie überprüft werden kann, ob der Benutzer seine Daten wirklich zu Recht anfordert. Und wir verwenden das vom Benutzer gespeicherte Cookie als Verifizierungsfaktor.
Das Projekt wurde kürzlich abgeschlossen, daher ist es noch zu früh, um über numerische Ergebnisse zu sprechen.
Artikelautor: Nikolay Eremin
PS Wir veröffentlichen unsere Artikel auf mehreren Websites der Runet. Abonnieren Sie unsere Seiten auf
VK ,
FB oder
Telegramm-Kanal , um mehr über unsere Veröffentlichungen und andere Maxilect-Nachrichten zu erfahren.