The AEP Field Change That Could Have Broken Everything — And the Scanner I Built to Prevent It

No dependency graph. No "find all references." No impact analysis. Just vibes and a prayer.

So naturally, I built one.

How We Got Here

Nobody noticed for months because:

1. Data ingestion was succeeding — the data matched the (wrong) schema perfectly

2. Segment builder doesn't flag when you compare a string field to a numeric literal

3. PQL expressions "worked" in dev (where the type was correct) and returned garbage in prod

Why You Can't Just Fix It

Changing a field type in AEP isn't a migration — it's a nuke. You can't alter an existing field's type. Profile enabled XDM schemas are append-only by design. So the "fix" is actually:

1. Create a *new* field with the correct type

2. Update every single thing that references the old field to point to the new one

3. Backfill historical data

4. Deprecate the old field

5. Try not to miss anything and blow up prod

Step 2 is where I started sweating. "Every single thing" includes:

And AEP's UI gives you... nothing. No search. No cross-reference. You're expected to manually click through every segment, every computed attribute, every dataset, and visually confirm whether it references your field.

For an enterprise platform where a single schema might back hundreds of segments across multiple sandboxes, that's not a plan. That's a liability.

Discovering What the APIs Could Do

Here's where it got interesting. I was initially resigned to the manual audit — open each segment, Ctrl+F the PQL, take notes in a spreadsheet. Then I started poking around the AEP API documentation, mostly out of curiosity and realized the data I needed was *all there*. Adobe just never built a UI for cross-referencing it.

{
  "id": "seg-123",
  "name": "High Value Loyalty Members",
  "expression": {
    "type": "PQL",
    "value": "loyalty.tierPoints > 5000 AND loyalty.status = 'active'"
  }
}

There it is. The field path, right in the PQL string. If I could pull every segment and regex across the expressions, I'd have my dependency map.

Four APIs. All documented. All returning exactly what I needed. Adobe had built the ingredients and never assembled the dish.

Building the Scanner

Once I knew the APIs had the data, the scanner was straightforward. Python, FastAPI, about 300 lines of actual logic.

def _field_matches(text: str, field_path: str) -> bool:
    pattern = re.escape(field_path) + r'(?![.\w])'
    return bool(re.search(pattern, text, re.IGNORECASE))

Word-boundary matching. Simple, but it eliminated every false positive I threw at it.

Same approach for computed attributes — pull them all, match the expressions. Datasets get filtered by schema ID if you have one, or by name/description search as a fallback.

One endpoint gives you the full picture:

GET /field-usage/scan?field_path=loyalty.tierPoints&sandbox=prod

{
  "field_path": "loyalty.tierPoints",
  "sandbox": "prod",
  "segments": [
    {
      "id": "seg-123",
      "name": "High Value Loyalty Members",
      "status": "ACTIVE",
      "evaluation_type": "batch",
      "pql_snippet": "loyalty.tierPoints > 5000 AND ..."
    }
  ],
  "computed_attributes": [
    {
      "id": "ca-789",
      "name": "lifetimeTierPoints",
      "status": "ACTIVE",
      "expression_snippet": "SUM(loyalty.tierPoints, 'P365D')"
    }
  ],
  "datasets": [
    {
      "id": "ds-456",
      "name": "Loyalty Events",
      "schema_id": "https://ns.adobe.com/tenant/schemas/abc123"
    }
  ],
  "summary": {
    "segments": 1,
    "computed_attributes": 1,
    "datasets": 1,
    "total_references": 3
  }
}

Three references. Not zero ("it's probably fine"). Not unknown ("let's just hope"). Three, with names, IDs, and the exact expressions. Now you can update each one, verify it, and move on.

What I Learned

The Takeaway

But here's the thing that still gets me: I shouldn't have had to build this. Every enterprise data platform — Snowflake, BigQuery, Databricks — has some form of lineage or impact analysis. AEP is a platform where a single field change can silently corrupt audience qualifications that drive millions of dollars in ad spend, and there's no built-in way to check what depends on what.

Until Adobe fixes that, at least now there's a scanner.

*If you've hit the same "what depends on this field?" wall in AEP, I'd genuinely love to hear how you dealt with it. And if you've found other gaps where the APIs expose data that the UI doesn't surface — that's usually where the best tooling opportunities are hiding. Drop it in the comments below.*