Nobody broke anything. Shopify, Stripe, the CRM and the helpdesk each created a customer record using whatever identifier they had at the moment they needed one, and none of those identifiers agreed. The systems are all correct in isolation. The person is the thing that got lost.

This post covers what actually breaks when you unify Shopify, Stripe, CRM and support data, and how to build the join so it survives guest checkouts, duplicate webhooks, refunds, currency conversion and deletion requests. It’s organized by failure family rather than by tool, because the tools get acquired and renamed every couple of years and the failures never change.

Failure family one: the join key is not the email address

Every one of these systems will happily give you an email address, which is exactly why so many pipelines join on it and quietly produce garbage.

Start with where identity actually lives in each system:

• Shopify has a customer ID, but an order does not have to be attached to one. Guest checkout produces an order with an email on it and no durable customer record behind it.
• Stripe has a customer ID, but only if a Customer object was created. Checkout Sessions that don’t create one are associated with guest customers instead, which Stripe groups in the Dashboard based on the same card, email or phone. That grouping is read-only and it is not an ID you can join on.
• The CRM keys on email in almost every default configuration, and cheerfully creates a second contact when the email differs by one character.
• The helpdesk keys on the requester’s email, which is whatever the person typed into a contact form or sent the ticket from. It is very often not the address on the order.

Here’s the part that stays invisible until someone finally checks: nothing errors. Every dashboard still returns a number. Lifetime value gets silently split across three profiles, so your LTV looks lower and your repeat-purchase rate looks worse than it is. Support metrics look better than they are, because a customer coming back with the same unresolved problem shows up as a brand new contact. You can run like that for a year without a single failed job.

Build an identifier table, not a fuzzy match

The fix is boring and it works: a surrogate person key, and a separate table of every identifier ever observed for that person, with the source that reported it.

-- One row per real human, generated by you, owned by you.
CREATE TABLE person (
  person_key      uuid PRIMARY KEY,
  created_at      timestamptz NOT NULL DEFAULT now(),
  merged_into     uuid NULL REFERENCES person(person_key)
);

-- One row per identifier per source. This is the whole trick.
CREATE TABLE person_identifier (
  person_key      uuid NOT NULL REFERENCES person(person_key),
  source          text NOT NULL,   -- shopify | stripe | crm | helpdesk
  id_type         text NOT NULL,   -- email | phone | shopify_customer_id | stripe_customer_id
  id_value        text NOT NULL,   -- already normalized
  first_seen_at   timestamptz NOT NULL,
  last_seen_at    timestamptz NOT NULL,
  PRIMARY KEY (source, id_type, id_value)
);

Normalization happens before the row is written, not in the join. Lowercase and trim emails, store phone numbers in E.164, strip whitespace from external IDs. Resist the urge to get clever with Gmail’s dot and plus handling. Stripping +tags is a business policy decision with real consequences, not a technical detail, and the same rule applied to a domain that treats plus addresses as distinct mailboxes will merge two genuinely different people.

Deterministic matching first, always. Exact matches on shared identifiers, transitively closed. Probabilistic matching on name plus address plus device is worth reaching for only when you have exhausted the deterministic keys, and it has an asymmetric failure mode: a household sharing one card gets collapsed into one person, and unmerging afterwards is expensive because every downstream system has already copied the merged key into its own records. Merges are cheap to make and painful to undo. Bias toward leaving two records separate.

One thing worth doing early on the Stripe side: when you create a Customer, write your own identifier into metadata. Stripe allows fifty key-value pairs per object, with keys up to forty characters and values up to five hundred, and it only returns metadata for requests made with a secret key. That’s enough room for a person key and an order reference, which turns a future fuzzy join into an exact one. Never put anything sensitive there.

Failure family two: webhooks arrive twice, out of order, or not at all

Both platforms are explicit about this, and both get treated as if they weren’t.

Stripe delivers at least once, does not guarantee ordering, and retries failed deliveries with exponential backoff for up to three days. The event id (the one starting evt_) stays identical across every retry, which makes it your deduplication key. Shopify sends X-Shopify-Webhook-Id for the same purpose, signs the raw body into X-Shopify-Hmac-Sha256, and states plainly that ordering isn’t guaranteed within a topic or across topics for the same resource. Shopify’s own documentation goes further and tells you not to rely on webhooks as your only source of data.

For a customer-data pipeline specifically, out-of-order delivery is nastier than duplication. Consider a customers/update that changes someone’s email arriving before the orders/create that was placed under the old address. Process those in arrival order and you attach the order to a person who doesn’t exist yet, or worse, to the wrong one. Order your writes by the event’s own timestamp, using X-Shopify-Triggered-At or the updated_at in the payload, and make profile updates last-writer-wins on that timestamp rather than on insertion time.

Do almost nothing in the handler

Verify the signature, claim the event ID, write the raw body to durable storage, return 2xx. That’s it. Identity resolution, CRM lookups and enrichment calls all belong in a worker reading from that store. A handler that tries to resolve identity inline will eventually be slow enough to time out, which triggers a retry, which arrives while the first attempt is still running.

Make the claim atomic rather than check-then-act, because two retries genuinely can land concurrently:

-- Atomic claim. If this inserts zero rows, someone already has it.
INSERT INTO webhook_event (source, event_id, topic, received_at, payload)
VALUES ($1, $2, $3, now(), $4)
ON CONFLICT (source, event_id) DO NOTHING
RETURNING event_id;

Return a 2xx for a duplicate. A duplicate is a success from the sender’s point of view, and returning an error just schedules more of them.

Signature verification has one recurring trap on the Shopify side: it runs against the raw body. Any JSON body parser that runs first will change the bytes and every signature will fail. Capture the raw body before parsing, and compare in constant time.

import base64, hashlib, hmac

def verify_shopify(raw_body: bytes, header_value: str, client_secret: str) -> bool:
    digest = hmac.new(
        client_secret.encode("utf-8"),
        raw_body,
        hashlib.sha256,
    ).digest()
    expected = base64.b64encode(digest).decode("utf-8")
    return hmac.compare_digest(expected, header_value)

Worth knowing before you spend an afternoon on it: after rotating an app’s client secret, Shopify notes it can take up to an hour before signatures are generated with the new one. If verification starts failing right after a rotation, that’s usually why.

And because delivery isn’t guaranteed, webhooks alone are never enough. Run a reconciliation job that pulls orders and customers modified since the last watermark and fills the gaps. This is the job that saves you during an outage on your side, and it’s the one people skip. If you’d rather not build the buffering and replay layer, managed webhook infrastructure like Hookdeck exists for exactly this, and self-hosting a small queue and worker on a modest VPS from somewhere like Contabo or InterServer is perfectly reasonable too. The point is that something has to catch what the webhook missed.

Failure family three: “revenue” means four different things

This is the one that turns into a meeting. Finance says the number is wrong. Analytics says the number is right. Both are correct, because they’re measuring different things and nobody wrote down which.

• Shopify reports gross sales at the moment the order is placed, in the store’s currency and the store’s timezone.
• Stripe pays out in batches, net of processing fees, refunds and disputes, on its own schedule, in the settlement currency of the account.
• A refund issued in Shopify and a refund issued in Stripe are two different events that may or may not be the same underlying money movement.
• A dispute lands days or weeks after the order and reverses revenue in a period that has already been reported.

There’s a structural trap here too. If the store runs Shopify Payments, there is no Stripe account for you to query. Shopify Payments is built on Stripe’s processing infrastructure, but it’s Shopify’s gateway, and payouts, fees and disputes live in the Shopify admin rather than behind a Stripe API key. Plenty of businesses end up with Shopify Payments handling storefront orders and a separate Stripe account handling subscriptions or invoicing, which means two payment systems, two payout schedules and one customer who has no idea any of this exists.

Do not build a single revenue column. Build separate fact tables at their natural grain (orders, order line items, payments, refunds, disputes, payouts) plus a bridging table that links a payout back to the transactions inside it. Then let each team define its own metric on top. Finance gets net settled cash. Marketing gets gross booked revenue. Neither has to be wrong for the other to be right.

Store every timestamp in UTC and keep the original timezone as a separate column. Store every amount in minor units as an integer alongside its currency code, and store the FX rate that was actually applied rather than recalculating it later from a rates table. Recalculated FX is the single most common source of “the number moved and nobody changed anything.”

On ingestion, Stripe Data Pipeline can push Stripe data directly into Snowflake, Redshift or Databricks as a data share, which removes a connector from the picture if you’re already on one of those. Otherwise a managed ELT tool like Fivetran or a self-hosted Airbyte will handle Shopify, Stripe, the CRM and the helpdesk with off-the-shelf connectors. Both routes are fine. The connector is genuinely the easy part.

Failure family four: deletion is the requirement nobody models

If you’re building this as a Shopify app, three compliance webhooks are mandatory: customers/data_request, customers/redact and shop/redact. You acknowledge with a 200 and complete the action within thirty days. shop/redact fires forty-eight hours after uninstall and covers the shop’s data. These are enforced at app review, so you’ll find out about them either way.

The interesting problem isn’t receiving the webhook. It’s that by the time it arrives, that person’s email exists in your raw landing zone, your staging tables, your identity table, your customer view, a BI extract, the CRM, the helpdesk, and a Slack message from a debugging session six months ago. A delete that only touches the golden record is not a delete.

The design decision that makes this tractable is to hold personal data in exactly one place. Every downstream table carries person_key and nothing else. Facts, aggregates, models, extracts and syncs all reference the key. When a redaction request lands, you redact one row set in the identifier table and the rest of the warehouse is already anonymous. Getting this right at schema-design time costs an afternoon; retrofitting it costs a quarter.

Practical pieces that make it real:

• Tag every table and column that can contain an identifier, in your catalog or in dbt metadata, and treat the tag list as the deletion scope.
• Partition the raw landing zone so you can rewrite a partition rather than scan an entire bucket looking for one email.
• Keep a deletion queue with a status per downstream system, including the CRM and the helpdesk, which have their own APIs and their own idea of what deletion means.
• Write down what you retain and why. Financial records generally have to survive a deletion request for tax and dispute reasons. Say so rather than promising a hard delete you can’t perform.

Failure family five: pushing the unified view back out

A customer view nobody can act on is a report. The value shows up when a support agent opens a ticket and can see subscription status and lifetime order count without switching tabs.

That’s reverse ETL, and the market is well served: Hightouch, Census (now part of Fivetran), Polytomic, RudderStack, and iPaaS-style tools like Workato if you need branching logic rather than field syncs. The warehouse-native argument is straightforward and mostly correct: your models already live there, and you avoid maintaining a second copy of the customer profile inside a vendor’s rigid schema. The counter-argument is also real. Reverse ETL is batch by nature, so if you need sub-minute reaction to an event, a packaged CDP or a direct event pipeline will serve you better, and you’ll be running several vendors plus warehouse compute plus the people to maintain the models.

Three things go wrong here more or less every time.

The write loop. You compute a churn-risk field and sync it into the CRM. Your ELT connector reads the CRM back into the warehouse. Now the computed field is an input to the model that computes it. This is genuinely hard to spot because nothing errors, the value just drifts. Namespace every synced field with a consistent prefix and explicitly exclude that namespace from ingestion.

The resync stampede. Incremental syncs push diffs and stay small. Change a model definition and the next run wants to update every record, which will meet a helpdesk API rate limit at speed. Cap the batch size, and treat a full resync as a planned operation rather than something a merge to main can trigger.

Syncing logic instead of keys. Push person_key into a custom field on the CRM contact and the helpdesk user. It makes the key searchable by agents, it gives the next pipeline a deterministic join, and it stops three teams from each rebuilding their own version of your matching rules.

A pipeline shape that holds up

Put together, the order of operations matters more than the tool choice:

1. Land raw. Every webhook body and every API page goes to immutable storage first, keyed by source and event ID, before anything interprets it.
2. Deduplicate on the provider’s event ID, atomically, with a retention window longer than the provider’s retry window.
3. Normalize identifiers into the identifier table as rows arrive, with the source recorded.
4. Resolve identity deterministically into person_key, as a scheduled job, never inside a request handler.
5. Build fact tables per system at their own grain, keyed on person_key, with no raw PII.
6. Model the customer view on top, in dbt or whatever your team already uses. The Fivetran dbt_customer360 package is a reasonable starting point if you want to see how someone else structured the identity step.
7. Activate a small, named, namespaced set of fields back into the CRM and helpdesk.
8. Run reconciliation and freshness checks on a schedule, and alert on them like you would any other production job.

Troubleshooting: symptom to root cause

These are the ones that come up repeatedly, and the check that usually settles them.

• Warehouse customer count is much higher than Shopify’s. Guest orders are minting a new person on every purchase. Check how many person rows have exactly one identifier and one order.
• Warehouse count is much lower. An over-eager merge rule. Look for person keys with an implausible number of distinct emails or shipping addresses attached.
• BI revenue doesn’t match Stripe payouts. Grain mismatch, not a data loss. Reconcile a single payout against its constituent transactions before touching anything else.
• A CRM field keeps flipping between two values. Write loop. Check whether the field’s namespace is excluded from your ELT source configuration.
• Recent orders missing, older ones fine. Webhook delivery gap. Confirm the reconciliation job ran, and check its watermark rather than trusting its exit code.
• Every Shopify signature suddenly fails. Either a body parser is running before verification, or the client secret was rotated within the last hour.
• Tickets attached to the wrong customer after a merge. The merge happened in the warehouse but the synced key in the helpdesk still points at the old person. Merges need to propagate outward, not just inward.

Common mistakes

• Joining on email in the model layer instead of resolving identity once, upstream.
• Treating webhooks as the system of record instead of as a low-latency hint, with a reconciliation pull behind them.
• Doing identity resolution, enrichment or CRM writes inside the webhook handler.
• Ordering profile updates by arrival time rather than by the event’s own timestamp.
• One revenue column that finance and marketing are both told to use.
• Storing amounts as floats, or recalculating historical FX from a rates table.
• Copying PII into every downstream table because it was convenient at the time.
• Reaching for probabilistic matching before the deterministic keys have been exhausted.
• Assuming a Shopify store on Shopify Payments has a Stripe account you can query.

Best practices worth the effort

• Own the surrogate key. Never let a vendor’s internal ID become the primary identity of a person in your systems.
• Write your person_key into Stripe metadata and Shopify customer metafields at creation time, so future joins are exact rather than inferred.
• Keep raw payloads immutable and replayable. Every model bug you’ll ever have is cheaper to fix if you can reprocess from raw.
• Version your matching rules and record which version produced each merge, so you can audit and reverse a bad rule.
• Alert on freshness and on row-count deltas per source, not just on job success. A connector returning zero rows exits cleanly.
• Reconcile one payout end to end by hand before you trust the automated version. It’s the fastest way to find a grain error.
• Document the metric definitions next to the models. Most “the data is wrong” tickets are definition disputes.

FAQ

Do I need a CDP to unify Shopify, Stripe, CRM and support data?

Not necessarily. If you already run a warehouse and have someone comfortable with dbt, ELT plus modelling plus reverse ETL covers the same ground with more control over the data model. A packaged CDP earns its cost when you need real-time behavioural segmentation, when nobody on the team can maintain models, or when marketing needs to ship changes without waiting on data engineering.

How do I handle guest checkout customers?

Create a person from the order’s email anyway, and mark the record as identity-weak. When that email later appears attached to a real Shopify customer or Stripe Customer object, the deterministic match links them and the order history follows. The mistake is discarding guest orders because they have no customer ID, which is exactly the revenue you most want attributed.

Should I sync everything into the CRM or keep it in the warehouse?

Keep the full picture in the warehouse and sync a deliberately small set of fields outward. The test is whether an agent or a rep will act on the field during a conversation. Lifetime value, subscription status, open ticket count and churn risk pass. A hundred-column profile does not, and it turns every model change into a rate-limit incident.

Why don’t my Shopify sales match my Stripe payouts?

Because they’re measuring different things at different times. Shopify shows gross sales at order time; Stripe pays out batched amounts net of fees, refunds and disputes, and the timing differs by days. Add currency conversion and a timezone mismatch and the numbers will never tie without an explicit bridging table linking payouts to the transactions inside them.

Can I use email as the primary key if my store requires account creation?

You can get away with it longer, but it’s still a bad primary key. People change email addresses, use one address for orders and another for support, and share addresses within a household. A surrogate key with an identifier table costs very little up front and means an email change is a new row rather than a broken join and a duplicate customer.

How do I test the identity resolution before trusting it?

Run it in shadow mode. Compute person keys without activating them, then have support pick twenty customers they know are duplicates and twenty they know are distinct, and check what the resolver did. That exercise finds normalization bugs and over-eager merge rules faster than any aggregate metric, because the people who answer the tickets already know where the duplicates are.

What’s the minimum viable version of this?

Raw landing with deduplication, an identifier table with deterministic matching, one fact table per source, and a single synced field into the helpdesk. That’s a couple of weeks of work and it removes most of the pain. Everything above it is refinement.

Conclusion: unify Shopify, Stripe, CRM and support data around a key you own

If you take one thing from this: the hard part of unifying Shopify, Stripe, CRM and support data is not moving the data. Connectors are commodity. The hard part is deciding what a customer is, writing that decision down as a key you own, and then refusing to let any downstream system quietly invent its own version of it.

Do the identity work first, land everything raw so you can reprocess when you get it wrong, and keep personal data in one place so deletion stays a single operation. The dashboards will follow. Skip that order and you get exactly the screenshot this post opened with, eighteen months later and with a lot more rows behind it.

Need help wiring this together?

I work on exactly this kind of plumbing: the unglamorous layer between an ecommerce platform, a payment processor and the tools your team actually opens all day. Things I can help with here:

• Designing the identity model (surrogate keys, identifier tables, deterministic matching rules) and auditing an existing one for over-merging.
• Building idempotent, signature-verified webhook intake for Shopify and Stripe, with a dead-letter path and a reconciliation job behind it.
• Setting up ELT into Snowflake, BigQuery, Redshift or Postgres, whether with Fivetran, self-hosted Airbyte, or Stripe Data Pipeline where it fits.
• Modelling orders, payments, refunds, disputes and payouts so finance and marketing can each get a number they trust.
• Reverse ETL back into the CRM and helpdesk without write loops, rate-limit incidents or a hundred junk fields.
• Making deletion and data-subject requests actually work across the warehouse, the raw landing zone and every downstream copy.

If you’re stuck on a specific piece, send me the concrete thing: a webhook payload, a schema dump, the query that disagrees with your Stripe payout report. It’s much easier to say something useful about a real artifact than about a diagram.

The post One Customer, Four Systems: Unifying Shopify, Stripe, CRM and Support Data appeared first on John Nessime.

You check. Every extraction job ran. Every ticket got a label. No rows dropped, no schema drift, no dead letters. Nothing is broken. The number is just useless, and it has been useless since the day it shipped.

That is the normal outcome for customer sentiment analysis built on CRM and support data. The connectors work, the model returns labels, the dashboard renders on schedule, and the output still cannot tell anyone whether customers are getting happier or angrier. These are not pipeline failures. They are measurement failures, which is exactly why your monitoring never catches them.

This post walks through the failure families I check first when a sentiment programme is producing numbers nobody trusts: where the label gets stamped, what happens when you average an ordinal scale, who is missing from the data entirely, why a general-purpose model misreads support English, where the CRM join breaks, and one regulatory boundary that catches more teams than it should. Then a pipeline shape that holds up, and the checks worth running before anyone puts this on a slide.

What the score is actually measuring

Before anything else, get specific about the unit of analysis. “Customer sentiment” is a phrase people use for at least four different measurements:

• Message sentiment — the tone of one comment in one thread.
• Ticket sentiment — usually the first inbound message, sometimes a rollup.
• Contact sentiment — one human’s tone across all their tickets.
• Account sentiment — the thing the business actually cares about, and the one nobody computes correctly.

Most stacks compute the second and label it the fourth. That single substitution causes more bad decisions than any model choice you will make downstream. A model with mediocre accuracy applied at the right unit beats an excellent model applied at the wrong one.

Failure one: the label is stamped at the wrong moment

This is the expensive one, and it is invisible from the pipeline side because nothing errors.

Zendesk’s intelligent triage is the clearest example because the documentation is honest about it. Zendesk states that most intelligent triage classifications are based on a ticket’s first message only, with an admin-configurable option to update topic and sentiment from the latest end-user message. If nobody turned that option on, your “customer sentiment” field is a permanent record of how annoyed someone was in their opening paragraph.

Think about what that does to a trend line. The opening message of a support ticket is negative almost by definition, because people do not open tickets to say things are going well. What you want to know is whether the interaction ended well. A ticket that opens furious and closes with a thank-you is a support win, and a first-message-only score records it as a loss forever.

Two consequences follow that people miss:

• Your sentiment metric is structurally incapable of moving in response to anything the support team does. Hire better agents, cut response time in half, rewrite your macros: the number will not budge, because it was set before any of that happened.
• It will move in response to marketing, onboarding and product changes upstream, because those change who opens tickets and how angry they are on arrival. So the metric drifts for reasons the team watching it cannot influence.

Zendesk also documents that when an agent corrects the sentiment field on a ticket, the correction does not retrain the model. Worth knowing before you build a human-review workflow on the assumption that it feeds back into anything. It gives you a cleaner column, not a better classifier.

The fix is to decide your stamping policy explicitly and store it. Score the first inbound message, score the last inbound message, and store both, along with the delta. The delta is the interesting column. Sentiment recovery within a thread is a far better signal of support quality than absolute sentiment ever was.

Failure two: averaging a scale that was never numeric

Zendesk exposes sentiment as five ordered values from Very negative to Very positive, and Zendesk Explore ships a prebuilt report for average customer sentiment on a one-to-five scale. Amazon Comprehend returns one of POSITIVE, NEGATIVE, NEUTRAL or MIXED plus per-class confidence scores. Google Cloud Natural Language returns a polarity score and a magnitude. Azure AI Language returns document- and sentence-level labels with confidences.

Only some of those are numbers, and none of the label sets are interval scales. The gap between Very negative and Negative is not the same size as the gap between Neutral and Positive, and there is no defensible reason to assume it is. So when you compute AVG(sentiment), you are doing arithmetic on rank labels and getting a value that has no units.

That would be a pedantic complaint if it were only a purity issue. It is not, because support sentiment distributions are usually bimodal. People write in angry or they write in grateful. Very few tickets are genuinely neutral. Take the mean of a two-humped distribution and you land in the valley between the humps, in a bucket where almost nobody actually is. Worse, the mean is stable there: the humps can grow, shrink and swap size while the average barely moves. That is your flat 3.2.

Use share metrics instead. They are ordinal-safe, they move, and they are directly actionable.

-- Share of negative tickets, weighted by account value.
-- Ordinal-safe: no arithmetic on the label itself, only counting.
SELECT
    date_trunc('week', t.created_at)                      AS week,
    COUNT(*)                                              AS tickets,
    COUNT(*) FILTER (
        WHERE t.sentiment IN ('very_negative', 'negative')
    )                                                     AS negative_tickets,
    ROUND(
        100.0 * COUNT(*) FILTER (
            WHERE t.sentiment IN ('very_negative', 'negative')
        ) / NULLIF(COUNT(*), 0)
    , 1)                                                  AS pct_negative,
    SUM(a.arr) FILTER (
        WHERE t.sentiment IN ('very_negative', 'negative')
    )                                                     AS arr_behind_negative
FROM   support_tickets  t
JOIN   crm_contacts     c ON c.id = t.contact_id
JOIN   crm_accounts     a ON a.id = c.account_id
WHERE  t.created_at >= date_trunc('week', CURRENT_DATE) - INTERVAL '26 weeks'
GROUP  BY 1
ORDER  BY 1;

Three things are happening there worth calling out. FILTER counts rows in a category without touching the label as a number. NULLIF stops a zero-ticket week from throwing a division error and silently killing the job. And the last column is the one executives will actually read, because a percentage of tickets is a support metric while revenue sitting behind negative sentiment is a business metric.

Failure three: the people who left never showed up in the data

Support data only contains customers who chose to contact you. That is a selection effect, not a sample.

The dangerous version is this: negative sentiment falls, everyone celebrates, and the actual cause is that the angriest cohort stopped writing in because they had already decided to leave. Silence reads as improvement. In a quarter where churn is rising, a falling negative-sentiment share is a warning sign, not a win.

You cannot fix this inside the support dataset, which is precisely why the CRM join matters. Two guards worth building:

• Contact rate as a companion metric. Tickets per active account per month, tracked alongside sentiment. Sentiment improving while contact rate collapses is a disengagement pattern, not a satisfaction one.
• Went-quiet detection. Accounts that used to file tickets regularly and have filed none in a defined window. In most books of business this list is a better churn predictor than the sentiment score itself, and it costs one window function to produce.

Failure four: the model learned someone else’s language

General-purpose sentiment APIs are trained largely on review-style and social text. Support English is a different dialect, and the mismatches are systematic rather than random.

• Problem statements are not complaints. “The export fails with a 500” is a factual bug report. Review-trained models frequently score it negative because failure vocabulary dominates.
• Politeness masks severity. A calmly worded message from an enterprise admin saying the production sync has been down since Tuesday is your worst ticket of the week and will score close to neutral.
• Domain vocabulary inverts. “Killed the process”, “the job died”, “aborted the run” are neutral technical descriptions carrying heavy negative weight in general corpora.
• Your own text pollutes the corpus. Auto-acknowledgements, signatures, quoted reply chains and CSAT survey footers all get scored if you feed the raw comment body. Quoted history is the big one: score a five-reply thread naively and you have scored message one five times.
• Non-native English reads flat. Simpler sentence structure and less emotional vocabulary push scores toward neutral for a whole segment of your customer base, which quietly biases any regional comparison.

Independent evaluations of the major cloud sentiment APIs on general text tend to land well below the accuracy figures in vendor marketing, and the providers frequently disagree with each other on the same input. Treat published benchmark numbers as irrelevant to your decision. The only number that matters is accuracy on a few hundred of your own tickets, hand-labelled by someone who understands your product.

Building the evaluation set

1. Pull a stratified random sample of tickets: across channels, across regions, across account tiers. Do not sample only recent tickets, or you bake in whatever was happening that month.
2. Have two people label independently, using a written rubric with worked examples of each class.
3. Measure agreement between the humans first. If your two support leads disagree on a third of the tickets, the task is underspecified and no model will fix that. Tighten the rubric and relabel.
4. Only then score the candidate models against the human labels, and look at the confusion matrix rather than accuracy. Where a model confuses classes tells you whether it is usable.
5. Freeze that set. It becomes your regression test when a vendor silently updates a model version.

Step three is the one teams skip, and it is the one that saves the project. Human agreement is the ceiling on model performance. There is no point chasing 90% against labels your own experts only agree on 70% of the time.

Failure five: the CRM join is where the value and the breakage both live

A sentiment label with no account attached is trivia. Two hundred irritated free-tier users and one irritated account paying for a third of your renewals are not the same event, and the raw ticket table cannot tell them apart.

The join from helpdesk to CRM is almost always on email, and email is a terrible key. Expect all of this:

• Shared inboxes such as ops@ or billing@, mapping to no single contact or to several.
• Personal addresses used by people who work at a customer, invisible to any domain-matching logic.
• Contacts who left and were deleted in Salesforce, HubSpot or Zoho CRM, orphaning every historical ticket they filed.
• Account hierarchies, where the subsidiary files the ticket and the parent holds the contract.
• Mergers and renames, which quietly rewrite history if your warehouse dimension is not versioned.

The engineering answer is boring and effective: treat unmatched tickets as a first-class, monitored quantity rather than something the join silently discards. Track match rate as a data quality metric with an alert threshold. When it drops, something changed in the CRM, and you want to know that before the number on the dashboard shifts for a reason nobody can explain.

Also version the account dimension. If you overwrite the tier or the ARR in place, then every historical aggregate silently rewrites itself the next time someone upgrades, and last quarter’s report stops reproducing.

The legal boundary that catches sentiment projects

This one is worth reading carefully if you have EU customers or EU staff, because the line does not fall where most people assume, and a lot of contact-centre software sells both sides of it in one bundle.

Article 5(1)(f) of the EU AI Act prohibits AI systems that infer emotions of a person in the workplace or in education settings. The prohibitions in Article 5 have applied since 2 February 2025, and breaches sit in the Act’s highest penalty band. What matters for a sentiment project is the scope, which is narrow on two axes at once:

• It applies to emotion inference from biometric data — faces, voiceprints, physiological signals. The European Commission’s guidance takes the position that inferring emotion from written text is not based on biometric data and therefore falls outside the prohibition.
• It applies to workplace and education contexts. Your customers writing into a helpdesk are neither.

So scoring the text of customer tickets and CRM notes generally sits outside the ban. Running voice-based emotion or stress analysis on your own support agents’ calls, for coaching or quality scoring, is the case the prohibition was written for. Plenty of platforms ship customer-facing text sentiment and agent-facing voice sentiment as adjacent features in the same product, and the pitch does not distinguish them. If you are the deployer, the compliance obligation is yours, and a vendor’s assurance is not a defence.

Separately, Article 50 carries transparency obligations for emotion recognition systems where they remain lawful. And none of this displaces GDPR: ticket bodies are full of personal data, and shipping them to a third-party API is a processing decision that needs a basis, a processor agreement and a residency answer.

I am an engineer, not a lawyer. Treat the above as the shape of the question to take to counsel, not as advice.

A pipeline shape that survives contact

Nothing exotic. The discipline is in what you store, not what you call.

1. Extract incrementally from the helpdesk and CRM on an updated-at cursor, not a full reload. Land raw payloads immutably before you transform anything, so a bad model run is re-runnable without re-hitting the source API.
2. Clean the text. Strip quoted reply chains, signatures, automated acknowledgements and survey footers. Keep the cleaned text as its own column so a scoring bug is debuggable later.
3. Redact personal data before it leaves your boundary. Regex handles the structured patterns: emails, phone numbers, card and account numbers, order IDs. Named-entity detection handles names and addresses. Amazon Comprehend exposes DetectPiiEntities and ContainsPiiEntities for this if you are already in AWS.
4. Score in batches, with the model identifier and version written into every row.
5. Aggregate at account level with share metrics and value weighting, against a versioned account dimension.
6. Alert on movement, not on level. Nobody acts on “sentiment is 3.2”. People act on “this named account’s negative share tripled in two weeks”.

Step four’s version column is the one people leave out and regret. Managed sentiment endpoints get retrained. When labels shift on unchanged text, the version column is the difference between a five-minute explanation and a week of forensics.

Here is what a batch call looks like against Amazon Comprehend, which is a reasonable default if your warehouse already lives in AWS:

import boto3

comprehend = boto3.client("comprehend", region_name="eu-west-1")

# BatchDetectSentiment accepts a maximum of 25 documents per call,
# and DetectSentiment caps each document at 5 KB of UTF-8 text.
# Chunk to both limits or the call fails for the whole batch.
BATCH_SIZE = 25
MAX_BYTES  = 5000

def score_batch(texts):
    payload = [t.encode("utf-8")[:MAX_BYTES].decode("utf-8", "ignore")
               for t in texts[:BATCH_SIZE]]
    resp = comprehend.batch_detect_sentiment(
        TextList=payload,
        LanguageCode="en",
    )
    # ResultList is index-aligned to the input; ErrorList holds
    # per-document failures. Read both or you lose rows silently.
    return resp["ResultList"], resp["ErrorList"]

The truncation on the encoded bytes rather than the character count is deliberate: the limit is measured in bytes, and a ticket full of accented characters or CJK text hits it much earlier than the character count suggests. The ErrorList read matters for the same reason a dead letter queue matters. A partial batch success that you never inspect is data loss that looks like a clean run.

For a quick sanity check on a single string before wiring any of this up, the CLI is faster than writing code:

aws comprehend detect-sentiment 
    --region eu-west-1 
    --language-code "en" 
    --text "Still waiting on the refund you promised last week."

{
    "SentimentScore": {
        "Mixed": 0.0033542951568961143,
        "Positive": 0.0086313202530145600,
        "Neutral": 0.1495875907897949,
        "Negative": 0.8384268 
    },
    "Sentiment": "NEGATIVE",
    "LanguageCode": "en"
}

Note that the response carries per-class confidences, not just the winning label. Store the whole SentimentScore object. A ticket scored NEGATIVE at 0.51 and one scored NEGATIVE at 0.98 are very different tickets, and the label alone throws that away. Confidence is also what lets you route only the ambiguous cases to a more expensive model or a human, instead of paying for everything.

Choosing where the model runs

Three broad options, and the trade-offs are real in both directions.

• Native helpdesk features. Zendesk intelligent triage, Salesforce Einstein, HubSpot and Zoho CRM all ship some form of built-in sentiment. Zero integration work, labels land on the ticket where agents can see them, and routing rules can consume them directly. You get the vendor’s definition of sentiment, no control over stamping policy beyond the toggles they expose, and data that is awkward to move.
• Managed NLP APIs. Amazon Comprehend, Azure AI Language and Google Cloud Natural Language. Per-character billing, no infrastructure, useful extras such as aspect-level or targeted sentiment. Comprehend’s targeted sentiment, which attaches sentiment to specific entities in the text, is English-only, and that constraint bites hard if your support volume is multilingual. Bill by volume of text, so a batch backfill of five years of tickets is a genuinely different cost event from steady-state scoring.
• Self-hosted transformers. A fine-tuned encoder model from the Hugging Face ecosystem, running on your own box. Best accuracy on your domain once tuned, no per-call cost, no text leaving your perimeter, which resolves most residency arguments before they start. In exchange you own model serving, evaluation and drift. A mid-tier dedicated server from a provider like Contabo or Hetzner runs CPU inference for batch workloads perfectly well, and batch is what this workload is. You do not need a GPU to score yesterday’s tickets overnight.

If you have no strong residency constraint and a small volume, start with a managed API. The self-hosted path is worth it when you have enough labelled data to fine-tune, or a legal reason the text cannot leave. Not before.

Troubleshooting

Sentiment is flat regardless of what the team does

Two likely causes. Either you are averaging an ordinal scale over a bimodal distribution, or you are scoring first messages only. Check the distribution shape first, since it takes one query. If it has two humps, switch to share metrics before you touch anything else.

Everything scores neutral

Usually a text-cleaning problem. If quoted reply chains, signatures and boilerplate survive into the scored text, the actual message is diluted by noise and the model regresses to neutral. Print the exact string you are sending for twenty tickets and read them. This bug is invisible in aggregate and obvious in the raw payload.

The trend shifted overnight with no matching business event

Check the model version column and the CRM match rate on the same day. A managed endpoint retrain and a CRM field change both produce exactly this signature. If you did not store the version, this is the moment you start.

One region always looks happier

Before concluding anything about that region, check the language distribution. Non-native English and machine-translated tickets both drift toward neutral, which shows up as “less negative” in a share metric. Compare like with like by language, or score in the original language where the provider supports it.

Batch scoring jobs fail intermittently

Almost always the document size limit, hit by one oversized ticket with a pasted log file or stack trace in the body. Truncate on encoded byte length before the call and check the per-document error list rather than assuming a successful HTTP response means every document scored.

Common mistakes

• Reporting an average of an ordinal label set and calling it a score.
• Scoring the first message and describing the result as customer satisfaction.
• Treating unmatched tickets as an inner-join casualty instead of a monitored metric.
• Sending raw ticket bodies to a third-party API with no redaction step.
• Discarding confidence scores and keeping only the winning label.
• Trusting a vendor accuracy figure over a few hundred of your own hand-labelled tickets.
• Overwriting the account dimension in place, so historical reports quietly stop reproducing.
• Assuming a helpdesk vendor’s compliance posture transfers to you as the deployer.

Best practices for customer sentiment analysis

• Write down the unit of analysis before writing any code, and make sure the dashboard label matches it.
• Store first-message sentiment, last-message sentiment and the delta. Report the delta.
• Use share-of-negative and value-weighted share, never a mean over labels.
• Keep a frozen, hand-labelled evaluation set and re-run it on a schedule as a regression test.
• Persist the model identifier, model version and full confidence distribution on every scored row.
• Redact personal data before the text crosses a network boundary, and log what was redacted, not the values.
• Monitor CRM match rate, contact rate and language mix alongside the sentiment number itself.
• Alert on named-account movement, not on the global level.
• Know which side of the biometric line each feature you enable sits on, and put the answer in writing.

Frequently asked questions

Is customer sentiment analysis accurate enough to act on?

For prioritisation and trend detection, generally yes. For individual decisions about a specific customer, no. The reliable pattern is to use it as a filter that surfaces conversations for a human to read, rather than as a verdict. Any single ticket’s label should be treated as a hint, not a fact.

Should I use my helpdesk’s built-in sentiment or build my own pipeline?

Start with the built-in feature. It is free or cheap, it lands where agents work, and it tells you within a month whether anyone actually uses sentiment for anything. Build your own when you need a different stamping policy, cross-system aggregation, account-value weighting, or control over where the text is processed. Those are the four reasons that justify the effort.

Can I use an LLM instead of a dedicated sentiment API?

You can, and the quality on nuance, sarcasm and domain vocabulary is usually better because you can describe your product and your customers in the prompt. The costs are latency, price per token at backfill scale, and output stability. Pin the model version, constrain the output to a fixed label set, and set temperature to zero, or you will get labels that drift between runs on identical text. A pragmatic middle ground is a cheap classifier by default with an LLM as a fallback on low-confidence cases.

How much historical data do I need before the trend means anything?

Enough to cover your seasonality, which for most businesses means at least a full year. Support volume and tone move with billing cycles, product releases, holidays and renewal periods. A quarter of data will show you a trend that is really just the calendar.

Does sentiment analysis on support tickets fall under the EU AI Act ban?

The Article 5(1)(f) prohibition targets emotion inference from biometric data in workplace and education contexts, and Commission guidance treats text-based sentiment as outside that scope. Scoring customer-written text is generally not caught. Voice or facial emotion analysis applied to your own employees is squarely the thing it prohibits. Transparency duties and GDPR obligations still apply regardless, and this is a question for your counsel rather than your engineer.

What is a good target for share of negative tickets?

There is no cross-industry benchmark worth quoting, because the number depends entirely on your product category, your support channels and how the model was calibrated. Your own baseline is the only meaningful comparison. Measure for a full cycle, then set targets against that.

How do I handle multilingual support volume?

Detect the language, store it as a column, and segment every report by it. Do not translate to English and then score, since translation flattens emotional register and adds a second error source. Check which of your provider’s features are English-only before designing around them; some advanced modes, including Comprehend’s targeted sentiment, are narrower than the base sentiment endpoint.

The one thing worth remembering

A customer sentiment analysis pipeline that runs cleanly every night and produces a number nobody can act on is not a partially working system. It is a broken one, and the breakage is upstream of anything your monitoring can see.

So before optimising a model or shopping for a platform, answer three questions in writing: which message gets scored, what unit the number describes, and which accounts it is weighted by. Get those right with a mediocre classifier and you have something useful. Get them wrong with the best model on the market and you have a very accurate description of how annoyed people were in their opening sentence.

Need help making this work on your data?

I build and fix the data plumbing behind customer analytics. On this particular problem, that usually means:

• Auditing an existing sentiment metric to find out why it never moves, and rebuilding it on share and delta metrics that do.
• Building incremental extraction from Zendesk, Salesforce, HubSpot or Zoho CRM into a warehouse, with cursor state, retries and dead-letter handling that survives an API outage.
• Fixing the helpdesk-to-CRM identity join, including shared inboxes, account hierarchies and a versioned account dimension so historical reports keep reproducing.
• Standing up a redaction layer so ticket text is scrubbed of personal data before it reaches any third-party model endpoint.
• Running a proper evaluation: stratified sample, dual human labelling, inter-rater agreement, confusion matrices across candidate models, and a frozen regression set.
• Setting up account-level alerting in Grafana or your BI tool that fires on movement in named accounts rather than on a global average.

If you have a dashboard that has been flat for months, send me the query behind it and a screenshot of the distribution. That is usually enough to tell you what is wrong before we talk about scope.

The post Customer Sentiment Analysis From CRM and Support Data: Building a Score You Can Actually Trust appeared first on John Nessime.

That divergence is not a bug. It is documented behaviour, sitting in one table in the AWS docs that almost everyone scrolls past. This post covers what Zendesk data integration with AWS Glue zero-ETL actually replicates, the entities where deletes silently never propagate, the configuration choices you cannot undo after creation, how to wire the three IAM roles involved, and how to monitor the thing so drift shows up as an alarm instead of a meeting.

What Zendesk AWS Glue zero-ETL actually gives you

Zero-ETL is AWS’s name for managed replication. You create a Glue connection to Zendesk, pick the entities you want, pick a target, and Glue handles the initial snapshot, the schema mapping, and ongoing change data capture. No Spark job. No bookmark logic. No pagination code hammering the Zendesk API and no retry handling for it.

Supported targets are a general purpose Amazon S3 bucket through the lakehouse architecture of Amazon SageMaker, S3 Tables through the same lakehouse, Redshift Managed Storage, or an Amazon Redshift data warehouse directly. Data lands as Apache Iceberg, which is what makes row-level updates and deletes viable on object storage at all.

What you give up is control. No transform step, no server-side filter, no column pruning at ingest. You get the entity as the connector sees it and you shape it downstream. For most support analytics that trade is fine. It stops being fine the moment your compliance team asks why deleted records are still queryable.

The delete gap: four of seven entities never remove a row

AWS Glue zero-ETL supports seven Zendesk entities. Only three of them replicate deletes.

• tickets – create, update and delete all propagate
• users – create, update and delete all propagate
• organizations – create, update and delete all propagate
• satisfaction-rating – create and update only, no delete
• articles – create and update only, no delete
• calls – create and update only, no delete
• legs (call legs) – create and update only, no delete

When a satisfaction rating disappears in Zendesk, the row stays in your lakehouse. Permanently. Nothing errors, IngestionSucceeded fires as usual, and the row count in that table only ever goes up.

Now think about what your CSAT query does. It averages a score column across a set of rows. If removed ratings never leave the target, your average drifts further from the source every cycle, and the skew is rarely random because retracted or disputed ratings are exactly the ones most likely to be removed. The same mechanism inflates knowledge base article counts, call volume, and any call leg analysis you build. It stays invisible until two dashboards get compared side by side.

How to design around it

You cannot make the connector track deletes it does not track. So stop trying, and split the problem instead.

1. Run two integrations, not one. Put tickets, users and organizations in a continuously synced integration. Put the four append-only entities in a second integration you can tear down and rebuild on a cadence that matches how much drift you can tolerate.
2. Treat the append-only tables as an event log, not as state. Query them through a view that reconciles against a periodic authoritative count, rather than trusting row presence to mean the record still exists.
3. Prefer status fields over row existence. Where an entity exposes a field describing its state, filter on that field downstream. Check which fields your entities actually return before you build on this, because coverage varies by entity.
4. Reconcile on a schedule. Pull counts from the Zendesk API for the four entities and compare against the target. Alert on divergence, not on an absolute number.

Splitting the integration costs you a second set of IAM wiring and a second thing to monitor. It buys you the ability to rebuild the drifting half without touching the half that is correct. That is a good trade.

Entity coverage is narrower than the Zendesk API

Seven entities is not the Zendesk API. Ticket comments, ticket metrics, ticket audits, groups, views, macros and SLA policy definitions are not part of the zero-ETL entity set. If your reporting needs first response time, the audit trail behind a status change, or custom field definitions, zero-ETL alone will not get you there.

The useful part is that the Glue connection you create is reusable. The same connection backs a normal Glue ETL job, so you can run zero-ETL for the bulk entities and a scheduled Spark job for the ones it does not cover:

# Read a Zendesk entity through the same connection
# used by the zero-ETL integration. ENTITY_NAME takes
# the entity name, not the label, e.g. "tickets".
zendesk_read = glueContext.create_dynamic_frame.from_options(
    connection_type="Zendesk",
    connection_options={
        "connectionName": "my-zendesk-connection",
        "ENTITY_NAME": "tickets",
        "API_VERSION": "v2"
    }
)

One schema detail worth knowing before you write a single downstream query: the connector converts struct and list types to strings. Zendesk custom fields arrive as arrays of objects, so they land as serialized text, not as a nested column you can address with dot notation. Partitioning is also not supported on the Zendesk source. Plan for a parse step in your silver layer rather than discovering it in a broken dashboard.

Two decisions you cannot change after creation

Most Glue settings are editable. These two are not, and getting them wrong means deleting the integration and starting over.

Continuous sync versus on-demand snapshot

By default the integration syncs continuously. Enable the on-demand snapshot setting and it does a single one-time replication with no ongoing CDC. That setting is locked once the integration exists. If you enabled it for a proof of concept and then decided you wanted CDC, you are recreating the integration and re-running the full load.

Refresh interval, and why your target choice locks it

The refresh interval controls how often CDC pulls run. It accepts anything from 15 minutes up to 8640 minutes, which is six days. Here is the part that catches people:

• If the target is Amazon Redshift, the refresh interval cannot be modified after creation.
• For other targets, including the SageMaker lakehouse on S3, you can change it later.

So the target you pick is not only an architecture decision, it is a flexibility decision. If you are not certain what freshness the business actually needs, land in the lakehouse first and query Redshift over it. You keep the ability to tune the interval once you have real usage data instead of a guess made in week one.

On cost: AWS does not charge separately for the integration itself. You pay for everything around it, target storage, Redshift or Athena query compute, S3 requests, Data Catalog usage and CloudWatch logs. A 15 minute interval on seven entities produces far more small-file churn and log volume than a 6 hour one. Set the interval from the freshness a human will actually act on, not from the smallest number the field accepts.

Wiring the three roles

There are three separate permission layers here and they fail in different ways, which is why “check IAM” is useless advice on its own.

• The Zendesk OAuth credential. The connector uses the authorization code grant, so you get redirected to Zendesk to log in and approve. You can rely on the Glue-managed client application and supply only your instance URL, or register your own OAuth app in the Zendesk admin center and provide your own client ID and secret. The resulting access token does not expire, which is convenient and also means a revoked app in Zendesk is something you will only discover through failed ingestions.
• The source role. This is what lets the integration read through the connection. It is a prerequisite for SaaS sources and it is the step most people miss, because creating the connection successfully does not mean the integration can use it.
• The target role and catalog policy. This is what lets the integration write. A misconfigured catalog resource policy puts the integration into NEEDS_ATTENTION, not into a clear error at creation time.

The source role policy looks like this. Note glue:RefreshOAuth2Tokens, which is the one people leave out and then spend an afternoon debugging:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GlueConnections",
            "Effect": "Allow",
            "Action": [
                "glue:GetConnections",
                "glue:GetConnection"
            ],
            "Resource": [
                "arn:aws:glue:*:111122223333:catalog",
                "arn:aws:glue:us-east-1:111122223333:connection/*"
            ]
        },
        {
            "Sid": "GlueActionBasedPermissions",
            "Effect": "Allow",
            "Action": [
                "glue:ListEntities",
                "glue:RefreshOAuth2Tokens"
            ],
            "Resource": ["*"]
        },
        {
            "Sid": "CloudWatchLogging",
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": ["*"]
        }
    ]
}

The trust policy allows glue.amazonaws.com to assume it. Then you attach the role to the connection, which is a CLI-only step and does not appear in the console flow:

aws glue create-integration-resource-property 
  --resource-arn arn:aws:glue:us-east-1:123456789012:connection/my-zendesk-connection 
  --source-processing-properties "{"RoleArn" : "arn:aws:iam::123456789012:role/zendesk-zetl-source"}" 
  --region us-east-1

If you skip this, the connection tests fine and the integration still cannot read. That mismatch is the single most common reason a first attempt sits in NEEDS_ATTENTION with no obvious cause.

Setting up the integration

1. If you are using your own OAuth app, register it in the Zendesk admin center under the API settings and note the client ID and secret. Store the secret in AWS Secrets Manager, one secret per Glue connection.
2. In Glue Studio, create a connection under Data Connections. Choose Zendesk as the connection type, supply your instance URL and environment, and complete the OAuth redirect.
3. Create the source role with the policy above and attach it to the connection using create-integration-resource-property.
4. Prepare the target: the Glue database or S3 Table bucket, the target role, the catalog resource policy, and any Lake Formation grants your account’s permission model requires.
5. Create the integration. Select entities, set the refresh interval, and decide continuous sync versus on-demand snapshot. Both of those are locked from here.
6. Watch the first full load complete before you point anything at the tables. Full load and CDC are separate load types in the metrics, and the numbers look very different.

Once it works, move it into code. Glue zero-ETL integrations are supported by CloudFormation and the AWS CDK, which is the difference between a thing one person built in the console and a thing your team can redeploy into another account.

Monitoring: the metrics that expose drift

Zero-ETL publishes to the AWS/Glue/ZeroETL CloudWatch namespace, with dimensions for integrationArn, loadType and tableName. The metrics are InsertCount, UpdateCount, DeleteCount, IngestionSucceeded, IngestionFailed and LastSyncTimestamp.

The obvious alarm is on failure:

aws cloudwatch put-metric-alarm 
  --alarm-name zendesk-zetl-ingestion-failed 
  --namespace AWS/Glue/ZeroETL 
  --metric-name IngestionFailed 
  --dimensions Name=integrationArn,Value=<your-integration-arn> 
  --statistic Sum 
  --period 3600 
  --evaluation-periods 1 
  --threshold 1 
  --comparison-operator GreaterThanOrEqualToThreshold 
  --treat-missing-data notBreaching

That one catches loud failures. It does not catch the quiet one, which is an integration that stops running entirely. For that, alarm on IngestionSucceeded with --treat-missing-data breaching over a window longer than your refresh interval. Absence of success is the signal, not presence of failure.

And here is the one specific to this post. Because DeleteCount carries a tableName dimension, you can see the delete gap directly in a graph. Plot DeleteCount per table. Tickets, users and organizations will show a nonzero line. Satisfaction ratings, articles, calls and legs will sit flat at zero forever. That flat line is not a broken metric, it is the behaviour, and having it on a dashboard is the cheapest way to keep the whole team aware of it.

Glue also writes a system table into the target database recording the outcome of each full load and CDC run, with per-run record, insert and delete counts. Query that when CloudWatch is not granular enough. If you already run Grafana Cloud or Datadog, pulling the AWS/Glue/ZeroETL namespace in alongside your existing infrastructure dashboards puts pipeline health next to everything else on call already watches.

Troubleshooting

Integrations move through Creating, Active, Modifying, Syncing, Needs attention, Failed and Deleting. What each one means in practice:

• Syncing means it hit a recoverable error and is re-seeding data. Not an emergency. Let it finish before you touch anything.
• Needs attention means you have to fix something, usually connection credentials, the source role, the target role, or the catalog resource policy. Once you fix it, there is no manual recovery action. Glue retries automatically on an exponential backoff schedule, so the gap between attempts grows over time. If you fixed a policy and nothing happened after two minutes, that is expected. Wait it out.
• Failed is terminal. Delete the integration and recreate it. There is no repair path.

For anything else, the CloudWatch logs emitted after each full load or CDC run carry the actual root cause. The console status is a summary, and a fairly lossy one. Read the logs first.

Common mistakes

• Building CSAT, article count or call volume metrics on raw row counts from the four entities that never delete.
• Creating the connection and assuming the integration can use it. The source role attachment is a separate CLI step.
• Choosing Redshift as the direct target during a proof of concept and locking a refresh interval you picked arbitrarily.
• Setting a 15 minute interval because it was available, then being surprised by small-file churn and CloudWatch log volume.
• Writing downstream queries that address Zendesk custom fields as nested columns. They arrive as strings.
• Alarming only on IngestionFailed, so a stalled integration produces silence and silence looks like health.
• Reaching for zero-ETL when the requirement is ticket comments or ticket metrics, which are not in the entity set at all.

Best practices

• Split delete-tracking and append-only entities into separate integrations so you can rebuild one without disturbing the other.
• Land in the SageMaker lakehouse rather than straight into Redshift unless you are certain about freshness. It keeps the refresh interval editable.
• Put DeleteCount per table on a dashboard. It makes an invisible behaviour visible to everyone, not just whoever read the docs.
• Define the integration in CloudFormation or CDK once it works, so the next environment is a deploy rather than a repeat of the console clicking.
• Keep a silver layer between the replicated tables and your BI tool. That is where you parse the stringified structs and apply the reconciliation logic, and it means schema surprises break one view instead of every dashboard.
• Document which entities do not track deletes somewhere your analysts will actually read, next to the tables, not in a wiki page nobody opens.

When to use something else

Zero-ETL is a good fit when your target is already AWS, your entities are in the supported set, and you want AWS to own the pipeline. It is the wrong fit if you need entities outside that list, need transformation at ingest, or need the same Zendesk data landing somewhere that is not AWS. Managed connector platforms like Fivetran or Airbyte cover a wider slice of the Zendesk API and will replicate to non-AWS destinations, at the cost of another vendor relationship, another bill, and data leaving your account boundary on the way through. If the seven entities cover your reporting, zero-ETL is cheaper and simpler. If they do not, forcing it is worse than paying for a tool that fits.

Frequently asked questions

Which Zendesk entities does AWS Glue zero-ETL support?

Tickets, users, organizations, satisfaction ratings, articles, calls and call legs. Tickets, users and organizations replicate creates, updates and deletes. The other four replicate creates and updates only.

Can I get ticket comments or ticket metrics through zero-ETL?

No. They are not in the entity set. Use a Glue ETL job against the same Zendesk connection, or a connector platform with broader API coverage, and join the result to your replicated tables downstream.

How fresh can the data be?

The refresh interval goes down to 15 minutes and up to six days. This is near real time replication, not streaming. If you need sub-minute latency on Zendesk events, zero-ETL is the wrong mechanism and you want webhooks into an event pipeline instead.

Can I change the refresh interval later?

Only if the target is not Redshift. With Redshift as the target the interval is fixed at creation. With the SageMaker lakehouse and other targets you can modify it afterwards.

Why is my integration stuck in NEEDS_ATTENTION after I fixed the permissions?

Because recovery is automatic but not immediate. Glue retries on exponential backoff, so if the integration has been unhealthy for a while the next retry may be some way off. There is no manual recovery command. Confirm the fix is correct, then wait.

Does zero-ETL cost extra on top of Glue?

AWS does not bill a separate charge for the integration itself. You pay for the surrounding services: target storage, Redshift or Athena query compute, S3 requests, Data Catalog usage and CloudWatch logs. Refresh interval is the main lever, since it drives how many small commits and log entries you generate.

Why do my Zendesk custom fields look like text?

The connector converts struct and list types to strings. Custom fields come through as serialized values rather than nested columns, so parse them in a downstream layer instead of querying them directly.

Conclusion

Zendesk AWS Glue zero-ETL removes a genuinely tedious pipeline from your plate. The setup is fiddly in the IAM layer and then it mostly runs itself, which is exactly the point of a managed integration.

The one thing worth carrying out of this post: four of the seven supported entities never replicate a delete. Satisfaction ratings, articles, calls and call legs only grow. Nothing warns you, every metric stays green, and your numbers drift a little further from Zendesk with every cycle. Design for that on day one, put DeleteCount per table on a dashboard, and you will not be the person explaining the discrepancy in a meeting six months from now.

Need help with your Zendesk to AWS data pipeline?

I work with teams building and fixing replication pipelines on AWS. On this kind of setup, that usually means:

• Auditing an existing Zendesk zero-ETL integration and quantifying how far the target has drifted from the source
• Designing the split between continuously synced and append-only entities, including the rebuild cadence and reconciliation queries
• Untangling the source role, target role and catalog policy layers when an integration sits in NEEDS_ATTENTION with no clear cause
• Building the silver layer that parses stringified Zendesk custom fields into something your BI tool can actually use
• Setting up CloudWatch alarms and dashboards that catch a stalled integration, not just a failed one
• Moving a console-built integration into CloudFormation or CDK so it can be deployed across accounts

Send me the integration status, a CloudWatch log excerpt, or the query that is giving you the wrong number, and I will tell you what I think is going on.

The post Zendesk Data Integration with AWS Glue Zero-ETL: The Delete Gap That Skews Your Numbers appeared first on John Nessime.