R&F

predic+on

Intro: inventory es+mator

Inventory es+mator:
Service that returns the users ids from the target
audience.
Special cases for R&F:
special +er (unicorn.aggregator.invest.rf) which can
return > 5k users. We will deprecate it as with sharding
support it's no longer necessary to get than many
users in 1 query.
addi+onal terms that return only (.1% or 1%) of users
sampled for predic+on.
POC: Ping (pchen), Oscar (obarracel)

Intro: predic+on data

Impression history (fetched from up2x for old
system, zippyDB for new system)
40 last days should be always uploaded - we
need at least 30, the rest in case we cannot use
some days.
In cases of incorrect or unusual history (usually
caused by SEVs) need to manually disable days
(predic+onIncorrectDays in congerator)
Other data in up2x: page event rates, user event
rates (click, share, like, x-out)

Intro: predic+on en+ty

e.g. curve version: was reused as predic+on version, indicates predic+on
system version (3 is www, 4 is new backend), this value is used to
determine in which system to reserve, cancel, nalize etc
enum with possible status types

Predic+on ow (starts in www)

In PHP runs as an async job.
when reques+ng a ho\ix need to request v9
push, by default not selected
Makes a thri_ request and calls backend.

Predic+on ow (backend)
aggregator sends requests to leaf
Every shard in every leaf:

fetch user ids from InvEst

fetch user history
Fetch inventory informa+on for every user
lter out ineligible impressions:

page type matching

page tab (device) matching
video eligibility (no feature phones)
booked impressions

run simula+on

leaf sums the results from all its shards and sends the response.
aggregator sums the results from leafs.
aggregator applies the margins
aggregator interpolates from the grid to nd the result matching the reach
or budget goal.

Predic+on ow (www again)

receive response, convert budgets to account
currency (backend operates on US cents) and
save the result to predic+on en+ty
if the request failed: save failure code in en+ty

Reserva+on ow
Runs with a global lock.
Run predic+on again to make sure inventory is s+ll
available

if predicted value (reach, impression, budget) hasn't changed

signicantly from the original predic+on (threshold dened in
congerator, currently at 5%) then reserve the input values
else return status FAILURE_PREDICTION_RESULT_CHANGED

When running predic+on in the reserva+on ow in every

shard we save the opportuni+es we will book.
Run actual reserva+on - it should always succeed, because
of the global lock no one else can book anything in that
+me period.

Debugging in www
If predic+on is failing the easiest way to debug
is to rerun it in your sandbox and look for
errors in slog.
If cannot repro in sandbox, but you have a
predic+on id, get AsyncJobID from en+ty and
go to piranha job archive.

Debugging backend
scuba
machine logs

Monitoring
We run a daily script that saves benchmark
predic+on results in scuba.
Any signicant change (>10% change in
budget, >5% in reach or impression) is
suspicious and should be inves+gated (alerts
will re).

New backend di tes+ng

Run local comparison between produc+on +er
and your devserver.

Weirdness
dangling reserva+ons
target spec eld size in en+ty is limited