Article Directory
How Residual/Long Tail Traffic Sells Ads
"In the Internet industry, how to use traffic to quickly monetize, selling advertisements is definitely the first choice. Especially in the state of the stock market, the overall value of traffic has become very precious, and how to sell tail resources has become a stumbling block on the road to monetization! "
Mining the value of long-tail traffic
In the middle and late stages of the development of Internet advertising platforms, the mainstream tonality of their own media has been recognized by the majority of advertisers. They bid for self-consistent traffic one after another, and the popular traffic is selling well all the way.
As a platform, in order to further expand revenue at this stage, we mainly start from two aspects. On the one hand, further explore the needs of advertisers, increase advertising exposure/filling, and attract more customers with high-quality conversion and quantifiable effects; on the other hand, seek the value of long-tail traffic that no one cares about on the platform to realize the overall Maximize the value of traffic.
Long-tail traffic, as the name suggests, is the end of the mainstream, and the remaining part of the traffic. For example, some academic traffic on the main interactive entertainment platform, this part of the traffic can hardly be sold on the platform, it is a surplus; because this part of the traffic is a vertical derivative outside the platform's main tone, It is of no value to entertainment and interactive advertisers, and it is tasteless to academic advertisers. This is the remaining traffic.
The outlet for long tail traffic
So where should the remaining traffic go?
One of the common industry practices is to transfer this part of the traffic to a third party, and the third party will sell the traffic. Today, I will introduce a project to mark the remaining traffic and transfer it to a third party.
2.1 Judgment of long-tail traffic
From a product point of view, we have introduced what is residual flow, so what should we do when judging the actual flow?
Here we adopt a strategy recommended by data analysts: localized real-time decision-making.
2.1.1 Data Locality
We know that in the Linux system, when the CPU accesses the memory, in order to improve the access efficiency, whether it is accessing instructions or accessing data, the accessed storage units tend to gather in a smaller continuous area. Here is the use of The principle of data locality.
The principle of locality is further divided into temporal locality, spatial locality and sequential locality.
Temporal locality: If an information item is being accessed, it is likely to be accessed again in the near future.
Spatial locality: Information that will be used in the near future is likely to be spatially adjacent to information that is being used.
Sequential locality: In a typical program, most instructions, except branch instructions, are performed sequentially.
Based on this, we use whether the advertisement is distributed as the basis for judgment: judge whether the user is the remaining traffic through the 24-hour advertisement delivery frequency of the user dimension. [If there is an advertisement, it is non-residual traffic; if there is no advertisement, it is the remaining traffic and marks the number of times]
Real-time marking of long tail traffic
We have a strategy for judgment, so we need to implement it. In order to achieve a better effect of the strategy, we will design a "real-time marking service for remaining flow" [marking remaining flow in real time - FlowRemainer].
We position the service data processing mode as a stream processing mode, and perform traffic marking by consuming Trace data streams in real time. The deployment method is based on the docker container.
3.1 Overall Link Layout of Trace Streaming Service
Trace relies on the advertising system platform as the data source, so we will not focus on it here, but briefly describe the relationship between the uplink and downlink.
ADS writes Trace into Kafka, and the data is sent to Hive for large-scale asynchronous task processing; at the same time, real-time stream processing services are built based on Kafka consumption, FlowRemainer is one of them, and other services can be expanded and constructed in this mode.
3.2 Architecture Hierarchy Diagram
We use the classic MVC architecture model as the basis for business-oriented architecture design of FlowRemainer.
The overall architecture is divided into three layers. The entrance is the proxy layer, which will convert service communication protocols and data formats; the middle layer is the business layer, which centrally processes business logic; the bottom layer is the deployment layer, which supports service deployment and delivery.
The business layer is divided into three layers. The upper layer is the Service layer, which encapsulates the external interfaces of each business; the middle layer is the Dao layer, which builds the instance objects that the business depends on; the bottom layer is the Level layer, which is the basic service that supports business realization.
3.3 Object Class Diagram
We design object classes based on abstract interfaces to maximize the scalability and maintainability of services.
The ... in the figure are all expandable parts.
3.4 Logic distribution diagram
Since the current main business of the service is real-time marking of remaining traffic, it is relatively simple, and only the overall logical distribution is described here.
The service is designed and implemented in the Goland programming language, which can support horizontal expansion by using its concurrent programming feature. A single node can generally support 15w+ QPS [the specific data is based on the resource specification], and the P99 takes 20ms.
service observability
For the service telemetry here, we choose to embrace cloud-native prometheus components. Due to the limited space, you can pay attention to the official account, see the follow-up article.