Mailchimp and CodeWords: keeping the audience honest
Segments that reflect what customers actually did, consent that survives crossing systems, campaign reporting where your other numbers live, and the merge field discipline that makes any of it work.
On this page
- What we'll cover
- Why segments drift
- What the Mailchimp API reaches
- Connecting it to CodeWords
- Eight automations worth building
- Consent, which is the part that matters
- Merge fields and tags, used properly
- Building it so it survives
- Limits worth knowing about
- What to build first
- Frequently asked questions
- Related reading
Mailchimp's own automation handles what happens inside Mailchimp: journeys, triggered emails, and behaviour based on opens and clicks. What it cannot do is know anything you have not told it, and most of what should decide who receives which email happens somewhere else entirely — in your store, your billing system, or your product.
So the work worth automating is mostly about keeping the audience honest: making sure the data Mailchimp segments on reflects what people actually did.
What we'll cover
- Why segments drift
- What the Mailchimp API reaches
- Connecting it to CodeWords
- Eight automations worth building
- Consent, which is the part that matters
- Merge fields and tags, used properly
- Building it so it survives
- Limits worth knowing about
- What to build first
- Frequently asked questions
Why segments drift
Tags get added and never removed. A contact tagged "trial" two years ago is still tagged trial. Segments built on tags nobody prunes overlap in ways that send the wrong campaign to real customers.
Derived state goes stale. "Active", "lapsing", and "high value" are all calculated from behaviour at a point in time. Applied once, they are wrong within weeks.
Behaviour happens elsewhere. A purchase, a cancellation, a support complaint, a login after six months of silence. None of it reaches Mailchimp unless something puts it there.
Merge fields fill up with whatever was convenient. A field holding a date in three formats, or a status somebody typed by hand, is a field no segment can use reliably.
Consent state diverges. Somebody unsubscribes in one place and stays subscribed in another. This one is not untidiness, it is a compliance problem.
What the Mailchimp API reaches
Lists and audiences hold your contacts, with member records addressable by a hash of the lowercased email address, which is worth knowing because it is how you update somebody without first searching for them.
Members can be created, read, updated, and archived, including status, merge fields, tags, and marketing permissions.
Tags can be applied and removed in batches, which is the practical unit of segmentation.
Segments can be listed, created, and their members read, including static segments you populate directly.
Campaigns can be created, scheduled, sent, and their reports read, including opens, clicks, and per-link detail.
Automations and journeys can be triggered for a subscriber, which is how an external event starts a native email flow.
Batch operations exist and matter, because updating many members one at a time will meet the rate limits quickly.
Webhooks fire on subscribe, unsubscribe, profile update, and cleaned addresses, which is what lets consent changes propagate outward.
Connecting it to CodeWords
CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.
- Open CodeWords and start a new automation.
- Describe what should happen in plain language to Cody, the automation builder, naming Mailchimp and whichever system holds the behaviour you want to segment on.
- Authorize the connection with an API key, noting that the key's prefix determines the data centre your requests must go to.
- Describe the exceptions: a member who does not exist, an address that has been cleaned, someone who unsubscribed since the data was pulled.
- Test against a small audience you control before pointing anything at your real list.
You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
Eight automations worth building
Purchase and cancellation sync. Apply and remove tags as customers buy, renew, and lapse, from whichever system owns that truth. The highest-value automation here, because it stops the sales sequence reaching people who already bought.
Derived segment recalculation. Recompute lifecycle tags nightly — new, active, lapsing, lapsed, won back — removing the old tag as well as adding the new one.
Consent propagation. An unsubscribe in Mailchimp reflected in your CRM and your store, and vice versa. The most important automation on this page and the one most often missing.
Engagement pruning. Contacts who have not opened anything in a long window tagged for a re-engagement campaign, and those who ignore that archived. Deliverability depends on list health.
Campaign reporting into your own numbers. Sends, opens, clicks, and attributed revenue delivered where the rest of your reporting lives, rather than in a separate dashboard nobody opens.
Bounce and complaint handling. A hard bounce or a spam complaint flagged on the customer record everywhere, not just in Mailchimp, since a dead address is dead for order confirmations too.
List hygiene reporting. Duplicates, addresses with obvious typos, and contacts whose merge fields are empty, reported for a decision.
Audience reconciliation. A weekly comparison between Mailchimp and your customer records, reporting the differences rather than silently fixing them.
Consent, which is the part that matters
Everything else on this page is tidiness. This part carries legal obligations.
Sync status, not just addresses. When an automation moves contacts between systems, carry the consent state and the date it was given. A customer record is not permission to market.
Treat unsubscribe as global by default. Somebody who opts out in one place has opted out. Propagating that promptly is the single most important thing this integration does.
Keep transactional separate from marketing. An unsubscribe from campaigns should not stop order confirmations. If your architecture cannot express that distinction, fix that before automating anything.
Record where consent came from. Checkout opt-in, a signup form, an import. When someone asks why they are receiving email, the answer should be retrievable rather than reconstructed.
Never re-add an unsubscribed contact. An automation that syncs customers into Mailchimp must check status first, or it will resurrect people who opted out, which is both a complaint and a compliance failure.
Archived and unsubscribed are different states. Know which your automation is using, because archiving somebody to tidy your count is not the same as recording that they opted out.
Merge fields and tags, used properly
Tags are for membership, things somebody is or has done. Applied and removed, never accumulated indefinitely.
Merge fields are for values you want to use in content or segment on numerically. Keep one thing per field and one format per field.
Decide what empty means. Not collected, not applicable, and unknown look identical and mean different things.
Keep the set small. A dozen deliberate tags with clear definitions beat forty accumulated ones nobody can explain. If nobody can say what a tag means without looking it up, segments built on it are not trustworthy.
Write derived values from one place. Two automations both writing a lifecycle field will fight, and the winner will be whichever ran last.
Building it so it survives
Make it safe to run twice. Updates by email hash are naturally repeatable, which is why using the hash rather than searching first is the better pattern.
Batch your writes. Updating members one at a time will meet rate limits. The batch endpoints exist for this.
Check status before adding anyone to anything. Unsubscribed, cleaned, and pending are all states where proceeding is wrong.
Report the outcome. A daily line with counts updated, tagged, and skipped makes silence meaningful.
Never let an automation send a campaign unread. Preparing and scheduling is fine; sending to a whole audience without a person reading it is how a wrong link or a wrong name reaches everybody at once.
Limits worth knowing about
The API key encodes a data centre, and requests must go to the matching one. An automation that works for one account and fails for another is frequently this.
Rate limits apply per account with limited simultaneous connections, so parallelism needs care.
Member identity is the lowercased email hash. Changing somebody's email address creates a different member rather than renaming the existing one, which surprises automations attempting to update it.
Cleaned addresses cannot be resubscribed by an automation, which is the platform protecting your deliverability rather than a bug.
Audience count affects billing, so an automation importing enthusiastically has a cost implication worth knowing before it runs.
What to build first
Consent propagation: an unsubscribe in Mailchimp reflected everywhere else. It is small, it carries the only compliance risk on this page, and it is the one people discover they needed after an awkward email.
Two habits make the difference. Run it alongside whatever happens now for a cycle and compare, since the disagreements are usually genuine discoveries. And have it report that it ran even when nothing changed, because a silent consent sync is indistinguishable from a broken one.
Frequently asked questions
Should I use Mailchimp's own journeys?
Yes, for anything driven by email behaviour and for the sending itself. Reach outside when the decision depends on data Mailchimp does not hold, which is most of what determines who should receive what.
How do I stop segments going stale?
Recalculate derived tags on a schedule and remove the old tag in the same operation as adding the new one. Almost every drifting segment is caused by an automation that only ever adds.
Can I update a member without searching for them first?
Yes — member records are addressable by the MD5 hash of the lowercased email address, so you can update directly. This makes updates naturally repeatable and considerably faster than search-then-write.
What happens if I try to resubscribe someone who opted out?
The platform will refuse for cleaned addresses and you should refuse for unsubscribed ones. An automation that syncs customers in must check status first, or it will re-add people who opted out, which is a complaint and a compliance problem rather than an inconvenience.
How do I get campaign results into our reporting?
Pull the campaign report after each send and write the figures where your other numbers live. Doing it on send rather than on request means the answer exists before anyone asks, and it lets you compare email against your other channels consistently.
Why does my API call fail with an authentication error that looks correct?
Frequently the data centre. The suffix on the API key indicates which one to address, and a request to the wrong one fails in a way that looks like bad credentials.
Can an automation send campaigns?
It can create and schedule them, and sending a campaign to a whole audience without a person reading it is a risk with no upside. Prepare and schedule; let someone read it first. Transactional and lifecycle messages are the exception, where the content is stable and the timing is the point.
How do I handle someone who changes their email address?
Treat it as a new member and archive the old one, recording the link between them somewhere you control. Mailchimp identifies members by a hash of the address, so an address change is not a rename, and an automation attempting to update the old record will simply fail to find them.
Should an automation manage audiences as well as members?
Rarely. Multiple audiences multiply your billing and fragment your segmentation, and most teams who have several would be better with one audience and tags. Where you genuinely need separate audiences, keep the automation explicit about which one it is writing to rather than inferring it.
How do I handle contacts who exist in several audiences?
Treat each audience as a separate world, because Mailchimp does: the same person in two audiences is two member records with independent status. An unsubscribe in one does not propagate to the other, which is a compliance trap and the strongest practical argument for consolidating onto one audience with tags.
What should the weekly reconciliation report contain?
Contacts in Mailchimp with no customer record, customers with no Mailchimp contact, and anyone whose consent state differs between the two. The third is the one that matters and the one nobody checks.