- ID
- ea9877c7-108f-4b0d-bd8e-11c12e1454a8
2026-06-04
Meetings
None
Tasks
DONE Update PR for BE-7818
- ID
- 3747b9c7-3820-84a3-71e5-69ec81de3a62
DONE Open a pull request adding share-able urls to Favorite Cookbooks
- ID
- 14485d1a-f10d-d76f-efcd-45e9be563626
Description
BE-7819 Exp 242 - Create sharable Favorites Cookbook shell on share
DONE Investigate issue with Exp 242 data for Fanny
- ID
- 0efc8bcf-201b-42a0-8e4a-c2de9b2e4ae6
Description
BE-7859 Investigate and backfill missing Favorites experiment data
Fanny got me a bunch of CSV files that I need to figure out what to do with.
I *think* this is an issue of the data being in prod but not making it to a data
lake or something, but I need to do some research.
https://hungryroot.slack.com/archives/C0B7CUKNZ6F/p1780531230664279
Notes
- Note taken on
That UUID format (3471c164-fb2d-...) is Segment's ajs_anonymous_id cookie —
same one used in SearchExecutedEvent (hrsearch/views.py:104). The CSV came
from a warehouse/Segment events table, not from MySQL.
This matters for the investigation: Fanny's data is from Segment event exports
(where tag preference events were fired with the pre-auth anonymous identity),
not from dim_customer_tags (which is derived from MySQL customer_tag). They're
two different data sources.
Next question to answer: did those Segment events fire for these customers but
the corresponding customer_tag MySQL rows are still missing, or does the row
exist in MySQL and the CSV is just showing you the Segment-side record for
context? Ask Fanny which warehouse table/query produced that CSV — that'll
clarify whether the gap is app→MySQL or MySQL→warehouse.
- Note taken on
Claude's take:
Source of truth: app/models/customer_tag.py → DB table customer_tag. This
stores customer tag preferences — each row links a Customer to a Tag with a
preference score and is_explicit flag.
The chain: Django app writes → customer_tag (MySQL) → ETL/dbt →
shared_model.dim_customer_tags (warehouse)
The analyst is saying some customer's tag data is absent from the reporting
table. Two possible causes:
1. App never wrote it — the CustomerTag row doesn't exist in customer_tag
table.This would be a bug in our preference-setting flow
(update_customer_tags in app/services/api/tag.py:167).
2. ETL didn't sync it — the row exists in customer_tag but the pipeline that
feeds dim_customer_tags missed it (replication lag, filter bug, failed
job).
How to distinguish: check if the row exists in MySQL directly: SELECT * FROM customer_tag WHERE customer_id = <id>;
If row exists → ETL problem, not our code. If missing → app didn't write it,
likely need to trace why update_customer_tags wasn't called for that customer.