Artikelverzeichnis
Wie Residual-/Long-Tail-Traffic Anzeigen verkauft
„In der Internetbranche ist der Verkauf von Werbung definitiv die erste Wahl, wenn es darum geht, Traffic schnell zu monetarisieren. Besonders in der Lage an der Börse ist der Gesamtwert des Traffics sehr wertvoll geworden, und Schwanzressourcen sind zu einem sehr wertvollen geworden.“ Stolperstein auf dem Weg zur Monetarisierung!“
Den Wert des Long-Tail-Verkehrs ausschöpfen
In der mittleren und späten Phase der Entwicklung von Internet-Werbeplattformen wurde die Mainstream-Tonalität ihrer eigenen Medien von der Mehrheit der Werbetreibenden erkannt. Sie bieten nacheinander für selbstkonsistenten Verkehr, und der beliebte Verkehr verkauft sich durchweg gut.
Um den Umsatz in dieser Phase weiter auszubauen, gehen wir als Plattform hauptsächlich von zwei Aspekten aus. Erforschen Sie einerseits die Bedürfnisse von Werbetreibenden weiter, erhöhen Sie die Werbepräsenz/-füllung und ziehen Sie mehr Kunden mit qualitativ hochwertigen Konvertierungen und quantifizierbaren Effekten an. Suchen Sie andererseits nach dem Wert von Long-Tail-Traffic, der niemanden interessiert die Plattform, um den Gesamtwert des Verkehrs zu maximieren.
Long-Tail-Verkehr ist, wie der Name schon sagt, das Ende des Mainstreams und des verbleibenden Teils des Verkehrs. Beispielsweise kann ein Teil des akademischen Datenverkehrs auf der Hauptplattform für interaktive Unterhaltung kaum auf der Plattform verkauft werden, es handelt sich um einen Überschuss; da dieser Teil des Datenverkehrs eine vertikale Ableitung außerhalb des Haupttons der Plattform ist, ist dies der Fall Für Unterhaltungs- und interaktive Werbetreibende hat es keinen Wert und für akademische Werbetreibende ist es geschmacklos. Dies ist der verbleibende Verkehr.
Das Outlet für Longtail-Verkehr
Wohin soll also der verbleibende Verkehr gehen?
Eine der gängigen Branchenpraktiken besteht darin, diesen Teil des Datenverkehrs an einen Dritten zu übertragen, der den Datenverkehr dann verkauft. Heute werde ich ein Projekt vorstellen, um den verbleibenden Verkehr zu markieren und an einen Dritten zu übertragen.
2.1 Beurteilung des Long-Tail-Verkehrs
Aus Produktsicht haben wir den Restfluss eingeführt. Was sollten wir also tun, wenn wir den tatsächlichen Fluss beurteilen?
Hier übernehmen wir eine von Datenanalysten empfohlene Strategie: lokalisierte Echtzeit-Entscheidungsfindung.
2.1.1 Datenlokalität
Wir wissen, dass im Linux-System beim Zugriff der CPU auf den Speicher die Speichereinheiten, auf die zugegriffen wird, tendenziell in einem kleineren zusammenhängenden Bereich gesammelt werden, um die Zugriffseffizienz zu verbessern, sei es beim Zugriff auf Anweisungen oder beim Zugriff auf Daten. Hier ist die Verwendung von Das Prinzip der Datenlokalität.
Das Prinzip der Lokalität wird weiter unterteilt in zeitliche Lokalität, räumliche Lokalität und sequentielle Lokalität.
Zeitliche Lokalität: Wenn auf ein Informationselement zugegriffen wird, ist es wahrscheinlich, dass in naher Zukunft erneut darauf zugegriffen wird.
Räumliche Lokalität: Informationen, die in naher Zukunft verwendet werden, liegen wahrscheinlich räumlich neben den verwendeten Informationen.
Sequentielle Lokalität: In einem typischen Programm werden die meisten Anweisungen, mit Ausnahme der Verzweigungsanweisungen, sequentiell ausgeführt.
Auf dieser Grundlage verwenden wir die Verteilung der Werbung als Grundlage für die Beurteilung: Beurteilen Sie anhand der 24-Stunden-Werbeauslieferungshäufigkeit der Benutzerdimension, ob der Benutzer den verbleibenden Verkehr erhält. [Wenn eine Werbung vorhanden ist, handelt es sich um Nicht-Restverkehr; wenn keine Werbung vorhanden ist, handelt es sich um den verbleibenden Verkehr und markiert die Häufigkeit]
Echtzeit-Markierung des Long-Tail-Verkehrs
Wir haben eine Strategie zur Beurteilung, also müssen wir sie umsetzen. Um eine bessere Wirkung der Strategie zu erzielen, werden wir einen „Echtzeit-Markierungsdienst für den verbleibenden Fluss“ entwerfen [Markierung des verbleibenden Flusses in Echtzeit – FlowRemainer].
Wir positionieren den Dienstdatenverarbeitungsmodus als Stream-Verarbeitungsmodus und führen eine Verkehrsmarkierung durch, indem wir Trace-Datenströme in Echtzeit verbrauchen. Die Bereitstellungsmethode basiert auf dem Docker-Container.
3.1 Gesamtlink-Layout des Trace-Streaming-Dienstes
Trace basiert auf der Werbesystemplattform als Datenquelle, daher werden wir uns hier nicht darauf konzentrieren, sondern kurz die Beziehung zwischen Uplink und Downlink beschreiben.
ADS schreibt Trace in Kafka und die Daten werden zur groß angelegten asynchronen Aufgabenverarbeitung an Hive gesendet. Gleichzeitig werden Echtzeit-Stream-Verarbeitungsdienste basierend auf dem Kafka-Verbrauch erstellt. FlowRemainer ist einer davon, und andere Dienste können dies sein in diesem Modus erweitert und aufgebaut.
3.2 Architekturhierarchiediagramm
Wir nutzen das klassische MVC-Architekturmodell als Grundlage für das geschäftsorientierte Architekturdesign von FlowRemainer.
Die Gesamtarchitektur ist in drei Schichten unterteilt: Der Eingang ist die Proxy-Schicht, die Dienstkommunikationsprotokolle und Datenformate konvertiert; die mittlere Schicht ist die Geschäftsschicht, die die Geschäftslogik zentral verarbeitet; die unterste Schicht ist die Bereitstellungsschicht, die unterstützt Servicebereitstellung und -bereitstellung.
Die Geschäftsschicht ist in drei Schichten unterteilt. Die obere Schicht ist die Serviceschicht, die die externen Schnittstellen jedes Unternehmens kapselt; die mittlere Schicht ist die Dao-Schicht, die die Instanzobjekte erstellt, von denen das Unternehmen abhängt; die untere Schicht ist die Level-Schicht, bei der es sich um den Basisdienst handelt, der die Geschäftsrealisierung unterstützt.
3.3 Objektklassendiagramm
Wir entwerfen Objektklassen basierend auf abstrakten Schnittstellen, um die Skalierbarkeit und Wartbarkeit von Diensten zu maximieren.
Die ... in der Abbildung sind alles erweiterbare Teile.
3.4 Logikverteilungsdiagramm
Da das derzeitige Hauptgeschäft des Dienstes in der Echtzeitmarkierung des verbleibenden Datenverkehrs besteht, ist dies relativ einfach und hier wird nur die gesamte logische Verteilung beschrieben.
Der Dienst wurde in der Programmiersprache Goland entworfen und implementiert, die mithilfe ihrer gleichzeitigen Programmierfunktion eine horizontale Erweiterung unterstützen kann. Ein einzelner Knoten kann im Allgemeinen 15 W+ QPS unterstützen [die spezifischen Daten basieren auf der Ressourcenspezifikation], und der P99 benötigt 20 ms.
Beobachtbarkeit des Dienstes
Für die Service-Telemetrie entscheiden wir uns für die Verwendung cloudnativer Prometheus-Komponenten. Aufgrund des begrenzten Platzes können Sie auf den offiziellen Account achten, siehe Folgeartikel.