Traffic Distribution and Allocation: Non‑Intervention vs. Intervention, Objectives, and Technical Solutions

In traffic‑distribution scenarios, two layers of demand are placed on algorithmic models: (1) non‑intervention – the model fully controls traffic distribution, and (2) intervention – traffic distribution can be adjusted by the model.

Non‑intervention (called natural traffic ) lets the model decide each user’s content presentation with the goal of maximizing the current module’s UV value. Characteristics include a black‑box decision process and performance far beyond human‑level performance (HLP).

Intervention (called allocation traffic ) is needed when short‑term UV value is insufficient for business goals such as strategic product exposure, inventory clearance, new‑product nurturing, or user‑experience guarantees. Allocation traffic is applied in the re‑ranking stage to fine‑tune the flow.

2. Goals of Traffic Decision

2.1 Further improve module effect – online scenarios suffer from Data/Concept Drift caused by marketing activities, external events, or seasonality. Natural‑traffic models (T+1 update + real‑time features) can capture drift but need time to adapt, and their strategies are often too rigid.

2.2 Focus on long‑term business value – Natural‑traffic algorithms solve efficient distribution, while allocation‑traffic algorithms solve effective intervention. The decision layer must balance short‑term profit with long‑term value.

3. Traffic Allocation Techniques

The real‑world pipeline consists of Recall → Filter/Merge → Fine‑ranking → Re‑ranking. Traffic decisions are made in the re‑ranking stage and answer two questions:

Which items should receive traffic support?

How should the supported items be allocated without harming current module value?

Two technical solutions are presented:

3.1 ML + OR

Using the open‑source OR‑Tools, the re‑ranking problem is modeled as a 0‑1 integer program. Key steps:

Define the solver: the Rerank Matrix maps pre‑ranking positions (columns) to post‑ranking positions (rows).

Define Boolean variables for each matrix entry.

Define constraints: each row and each column sums to 1; optional category‑diversity constraints using a CateInfoMatrix.

Define the objective: combine pre‑ranking CTCVR and traffic demand into an OrgScoreWeight , weight each position with PosWeight , and maximize the sum of Object_Info .

Solve the optimization in real time (adds ~20‑30 ms latency, which can be mitigated by limiting the re‑ranking scope, variable count, or T+1 calls).

3.2 Control‑Theory PID

The PID (Proportional‑Integral‑Derivative) controller builds a real‑time feedback loop. Sensors collect data each time slice, compute the error against a reference, and the controller updates parameters to keep the metric within the desired range.

In the traffic‑decision context, the re‑ranking problem is transformed into a budget‑spending problem similar to programmatic advertising. Each position’s CPM is estimated, and the budget consumption of supported items defines the objective. Constraints include total spend < total budget and a soft CTR lower‑bound for supported items.

Dynamic PID parameters (proportional, integral, derivative weights) are updated each time slice based on the error, allowing the system to adapt to rapid data changes. Advantages: decoupled real‑time solving and parameter updates; disadvantages: instability when data are highly volatile.

4. Conclusion

This document summarizes the phase‑wise work of the Yanxuan traffic‑decision project, outlining both the ML + OR and PID‑based approaches for efficient and effective traffic allocation. Feedback and discussion are welcomed.