DTC and CPG e-commerce is the vertical we hear the most automation demand about and find the least operational detail written about. Amazon Ads optimizers, review-sentiment dashboards, and competitor ad monitors get pitched constantly, usually with a diagram and no account of what breaks in practice. We built three small workflows sized for a first engagement week. One runs live today, one runs real analysis over fixture input, and one is wired and waiting on a client credential.
keyword-oracle needs no credential
Amazon's autocomplete endpoint takes no authentication, and it has a trap that would have made this workflow look live while returning nothing. A request without the mid=ATVPDKIKX0DER parameter (Amazon's US marketplace ID) comes back HTTP 200 with an empty suggestions array, for iphone as much as for a niche seed term. There is no error and no block, only a response that reads as "no demand for this term" when the real cause was a malformed request. We found it by testing the endpoint directly before building the workflow, and the fix, one added parameter, is documented inline in the Code node that calls it.

For each seed term the workflow sends one bare query plus 26 more with a letter of the alphabet appended, so 27 sequential requests per seed at 350ms apart, capped at three seeds per run. A suggestion's rank in Amazon's own response is a demand signal, so the workflow sums 1/rank across every prefix a term surfaced under rather than inventing a scoring model of its own. We ran it against the live instance on 2026-08-10: execution 501, 54 real requests for the default seeds "collagen powder" and "dog probiotic," 526 suggestions collected, and a Telegram report delivered as message 127. Nothing here needs a client account or an approval wait, which makes it usable before a contract is signed.
review-miner splits into two tiers
The split in this workflow is what makes the private-where-it-matters pitch concrete. The input leg, which will eventually take a client's real review export from Amazon, Shopify, or Yotpo, runs today against 20 hand-authored fixture reviews for a fictional product, because no client feed exists yet. The analysis leg runs for real. It calls our own Ollama endpoint (qwen2.5:7b-instruct on the Mac Studio, over Tailscale), which is infrastructure we already control, so there was nothing left to gate it on.

That distinction matters because reviews carry customer data: names, order numbers, and complaints in the customer's own words. None of that text has to reach a third-party API to be analyzed. We ran the fixture set end to end on 2026-08-10 as execution 502, four sequential Ollama calls batching five reviews each. All 20 reviews were classified with no analysis errors, in a distribution of 8 positive, 6 negative, 3 neutral, and 3 mixed, and the Telegram report arrived as message 128.
One result from that run is worth flagging. In the batch covering reviews r11 through r15, the model attributed the phrase "evened out my skin tone" to review r13 as well as to its correct source, r14, so an attribution bled across two reviews inside one batch call. The per-review JSON schema and the parsing around it worked correctly. The failure was in the model's judgment within a batch. A client selling this at scale would want to know that before deciding whether to shrink the batch size or add a verification pass.
ad-library-monitor is deployed inactive
The third workflow watches competitors' Meta Ad Library pages through Apify, diffs each pull against a durable snapshot in an n8n Data Table, and reports new and killed ads. Marain has no Apify account today, so this one ships as a wired template rather than a standing monitor, deployed inactive until a client provisions a token and a list of competitor pages to track. The Apify call is written in full. Setting that token in the box's environment and passing it through the compose file turns it on with no change to the workflow logic.
We verified the diff logic using two hand-authored snapshots for three fictional brands that differ by exactly two events: one ad killed, one launched. Two consecutive runs against the live instance caught exactly that. Run 503 seeded the table with five ads and zero kills. Run 504 reported one new ad and one killed ad, matching the planted change, with the four unaffected ads carrying their original first-seen timestamps forward.
What each tier claims
None of these three claims to be more finished than it is. keyword-oracle runs live, for any client, unmodified, at no setup cost. review-miner's analysis is live today, and its input leg needs one node's data source swapped once a client export exists. ad-library-monitor is tested logic waiting on a budget and a competitor list. Overclaiming what a build does is the failure mode we work hardest to avoid. If you want a read on which parts of your own automation stack are actually running, that is one of the things the audit is for.