Issue #4: Try this this week: mx-data-explore
Split a multi-brand account into its real brands. Plus what we shipped this week.
Fourth issue, same shape: one skill to try, what we shipped, one question for you.
Try this this week: mx-data-explore
The problem. Plenty of agencies run several brands under a single Amazon seller account, separated only by a label on the retail and ads records. Pull numbers for that account and everything lands in one pile: you cannot see how much of the catalog or ad spend belongs to which brand, or how much carries no label at all. One brand's launch hides inside another brand's baseline, and a report that looks flat is really two stories averaged together.
The solution. mx-data-explore is a read-only way to look straight at your MixShift warehouse: sample a table, run a query, export to CSV. This week it gets sharper for multi-brand accounts. The warehouse now reports the distinct brand labels on the retail and ads sides, how much of your spend still has no label, and how well the two sides agree. No full brand setup required. Sign in and ask.
Try this: open Claude with the MixShift plugin and say:
"what brands do I have?"
You will get the brands and sub-brand labels under your account, with the unlabeled share called out. From there, sample or export any slice for your own analysis.
This week in MixShift
What we shipped this week. Full notes at mixshift.ai/releases; deeper how-to lives in the knowledge base.
1. Sub-brand discovery for multi-brand accounts
If you run several brands under one account, the platform now reads them as distinct brands. New queries report the labels on each side, how much of the catalog or ad spend has no label yet, and how well retail and ads agree. Brand-context queries also take optional label filters, so a single brand can be read on its own.
Now you can: see each brand under a shared account on its own terms, and find the unlabeled spend that was hiding in the account total.
2. Know which filters a query actually applied
Warehouse queries are deliberately tolerant: if a deployment does not recognize a filter you sent, it drops that filter and still returns a result. Useful for shipping on separate schedules, but a dropped filter used to look exactly like an applied one. Now every successful query lists the parameter names it actually bound, so you can confirm a filter took effect before trusting the result. Names only, never values.
Now you can: trust that a filtered pull was really filtered, instead of reading an account-wide number as a brand-level one.
You are on plugin version 0.8.7. To pick up the newest release, open the plugin and say "what's new with MixShift?" or "update MixShift."
What can we solve for you?
Reply to this email. It goes to MixShift, and every reply gets a personal answer. If we already solve your problem, we point you at the skill. If we build it, we ship it with your name on the release note.
Don't have the plugin yet? Get it here.
Talk next week.
MixShift