projectloop-ad

The problem

The team describes loop-ad as a platform that collects behavior such as searches, views, clicks, and bookings, then recommends audiences for a campaign. Those audiences are connected to ad generation and experiments, and experiment results inform the next decision.

My work focused on keeping the audience shown at recommendation time consistent with the audience assigned to the actual experiment. If those sets differ, the result is hard to trust and the decision is hard to reproduce.

Role and scope

My published team role is Data & AI Engineer. Public pull requests verify the following work.

  • Audience calculation in a 64-dimensional behavior coordinate system
  • ANN candidate verification with exact cosine and raw event conditions
  • Candidate source snapshots and selection-level final snapshots
  • Promotion-level exclusion and reservation lifecycle
  • Explicit binding between analysis, generation, segment scope, and each run
  • Revision-aware projection contracts across PostgreSQL and ClickHouse
  • Rerunnable migrations and legacy data compatibility checks
  • Sealed evaluation on the full Expedia source and reevaluation on external data

This does not mean I built the whole platform or its infrastructure alone. The Dashboard, other backend services, and AWS infrastructure are team-wide work.

Constraints

Recommended candidates can contain the same users. Once users are confirmed for a promotion, they must not reappear in later recommendations or experiments. PostgreSQL search and ClickHouse behavior counts also need to apply the same exclusion revision.

Legacy paths and existing data had to remain valid. The Data Contract migration must be deployed before the V2 contract is activated, and the Dashboard must distinguish source snapshot counts from the final allocation for a selected combination.

Implementation

Source snapshots preserve each candidate's original meaning and members. Confirmation resolves overlap only among the selected one to three candidates and creates a final snapshot for each segment. The allocation plan fixes the selection, policy version, and exclusion revision.

Each promotion run binds an explicit analysis, generation, and segment scope. Assignment reads only final snapshot members bound to that run. It does not rerun ANN search or winner calculation.

Data contracts and service boundaries

Decision, Dashboard, PostgreSQL, and ClickHouse must interpret IDs, states, revisions, and lifecycle transitions in the same way. The Data Contract added snapshots, allocation plans, exclusion state and members, and run target bindings.

The ClickHouse projection is revision-aware so a delayed lower revision cannot replace newer state. A new V2 analysis is blocked when the ClickHouse checkpoint trails PostgreSQL's current revision.

Evaluation and known limits

The public pull requests record canonical schema application, rerunnable migration chains, normalized DDL parity, snapshot overlap rules, reservation transitions, and run binding checks.

The sealed evaluation passed most criteria related to selecting audience candidates, but failed the mean absolute error threshold for expected conversion rate. Finding a useful audience and estimating its conversion rate accurately are different problems. Reevaluation on external data does not prove complete generalization.

What I learned

A data contract is more than matching table shapes. It must define when a snapshot is created, who can change it, which operations stop when a revision lags, and how retries or roll-forward deployment preserve previous decisions.

Recommendation quality alone does not create an operable decision system. The evidence shown in the interface and the audience used in execution need to live in the same lifecycle so the result can be explained and tested again.

Public sources