Something new at Databricks

Test recommendations in stores while purchases arrive days later

Published Nov 6, 2026

You’re the solutions / forward deployed engineer. Your team is in the room.

The setting

' is a customer data platform that merges scattered customer records into single profiles and builds audiences for marketing. It lets marketing and data teams use customer data without copying it into a separate system.

A reusable evaluation integration needs a stable contract before the retailer agrees what evidence it wants.

Operators need a credible purchase result, while delayed POS outcomes and competing evaluation questions pull the first version in different directions.

Who you’d be doing this for

“Someone asked how many purchases happened because of the recommendations, and I had to send another attributed-sales chart.”

Som Boonmee · Marketing Operations Manager · a character in this brief

Must explain whether personalized recommendations justify expanding audience activation into more stores.

What is at stake

A retailer needs proof of additional store purchases, but its POS outcomes arrive two to seven days late. You must choose what reusable integration operators can trust and run themselves.

Why it isn’t already fixed

Every obvious fix costs something else. That’s the part you’d have to decide.

  • credible lift evidence vs accessible operation
  • one customer's conventions vs reusable contracts
  • early results vs delayed purchases
  • one-off study speed vs independent repeatability

Why Databricks

Governed audience decisions in Unity Catalog and operational signals in Lakewatch provide the foundation for a customer-operated evaluation pattern.

Written with these in mind

Forward deployed engineersEvaluation-focused solutions architectsPartner integration specialists

Not your kind of problem? 115 more at Databricks, or browse every organization.

Where the organization context comes fromThe postings this brief was written from, and the reporting read before it.

The organization context comes from public information. The situation and characters are written for the brief.

Job postings it was written from

Public descriptions of the work at Databricks. They are listed as sources, not as openings. The lines under a posting are its own words, where it meets this brief.

This is the setup. The work is inside.

Running it puts you in the room: the full situation and its constraints, stakeholders who push back in their own words, and the decisions that are yours to make. What you produce becomes a Day One Plan — work you can show someone instead of describing.

Other live briefs connected to this one, and what connects them.

Similar problems at other organizations

Like this one, each of these is about figuring out which problem is actually worth solving.

The same setting, from another role

Each is set around Databricks’s CustomerLake, written for a different role. They’re separate briefs, not the same scenario.

Other problems with a similar purpose

In each of these, as in this one, the aim is to turn a person's earliest brush with a product into a habit they keep coming back to.