Question 1

What can Polytomic write into Chameleon?

Accepted Answer

User profiles and company profiles, including custom properties on both. New properties you map are tracked and sent as attributes, so there is no separate step to define them in Chameleon first. Write modes are create, update, and update or create. Events are not supported, and there is no delete or replace mode. That covers the reverse ETL targeting use case well, since Chameleon already captures product behavior and what it needs from you is the account context around it.

Question 2

How does identity matching work?

Accepted Answer

Profiles can match on the Chameleon ID, your own UID, or an email address; companies on the Chameleon ID or UID. When you use the Chameleon ID it is applied directly, while UID and email require a lookup request per record, so those syncs pace slower. Records with a blank identity are skipped rather than creating an anonymous profile. One caveat worth planning around: Chameleon can silently drop an email it considers invalid while accepting the rest of the record, which produces a duplicate instead of an update, so UID is the safer key.

Question 3

How does Polytomic handle large audience syncs?

Accepted Answer

Writes are batched at up to a hundred records per request against Chameleon's batch endpoints, which keeps sizeable syncs manageable. The identity lookups for UID and email based matching are not batched, though, so a sync keyed on those does one lookup per record before the batched write. Rate limited responses honor Chameleon's own wait and retry headers, falling back to geometric backoff. If throughput matters, keying on Chameleon ID avoids the lookup entirely.

Question 4

Will I see per record success or failure?

Accepted Answer

Not at record level, and it is worth knowing. Batch responses are not parsed per record, so a failed HTTP response marks the whole batch as failed and a successful one marks it all successful. Insert versus update counts are also not reported separately. In practice that means sync logs tell you whether batches landed rather than which individual profiles were affected, so validating a sample in Chameleon after a first run is a sensible habit.

Question 5

Why sync profile attributes instead of instrumenting them in the app?

Accepted Answer

Because the attributes that make in product targeting useful cannot be known client side. Contract value, plan tier, renewal date, support ticket volume, and health score are computed from systems your frontend has no access to, and hardcoding them into tracking calls means an engineering ticket every time a definition changes. Reverse ETL keeps that logic in your data warehouse where analytics and finance already agree on it, and keeps Chameleon updated on a schedule so product and growth teams can target on it directly.

Chameleon

Perfect pairings

User and company profiles

Batched writes

Flexible identity

Example workflows

What you can sync

From your sources

To Chameleon

How it works

How to set up

Frequently asked questions

Why teams choose Polytomic

No engineering required

Flexible data modeling

Handles scale automatically

Start syncing your data with Chameleon in minutes

More integrations beyond Chameleon