Piwi field notes · 3 min read
How we automated campaign-link preflight
One local workflow removes repeated URLs and finds missing attribution parameters, insecure links, and unapproved hosts.
Run this workflow & inspect the verified result →The business task
A newsletter or paid campaign can contain several versions of the same landing-page link. Before launch, a marketer checks the destination, HTTPS, and campaign attribution fields. Those checks are repetitive enough to automate, but they need to return specific findings rather than an unexplained pass or fail.
We built campaign-link-audit around an authored four-link launch checklist: one correct link, a duplicate of it, a link with incomplete UTM fields, and an HTTP link to a host outside the approved list. The workflow page includes the actual locally executed verification record. No client campaign or revenue result is implied.
The tool chain
list.unique removes exact duplicate strings while preserving their first occurrence. A mapped step calls url.inspect for each remaining link. These calls parse URL components locally; they do not visit the destinations or follow redirects.
campaign.review consumes the parsed records and the duplicate count. It checks HTTPS, exact hostname membership in allowedHosts, and the presence of non-empty utm_source, utm_medium, and utm_campaign values. Repeated UTM keys are flagged because they can be ambiguous for downstream systems.
What the actual run returned
Four submitted links became three unique links, with one duplicate removed. Two unique links were flagged. The incomplete social link was missing utm_medium and utm_campaign. The other-host HTTP link failed the HTTPS and approved-host checks.
The workflow returned a per-link issues list and summary counts: uniqueLinks 3, flagged 2, duplicatesRemoved 1. Its readyForReview value was false. A marketer can correct those two links and rerun the exact same checks before scheduling the campaign.
Run it for a launch
After connecting Piwi, call piwi_workflow_campaign_link_audit with urls and allowedHosts. Supply hostnames such as shop.example.com without a scheme or path. The whitelist is an exact host comparison, so intentionally include each approved subdomain.
The workflow accepts at most 20 input URLs. A malformed URL or a URL containing embedded credentials causes its inspection step to fail and stops the final review. It never repairs or rewrites tracking values silently. The workflow page contains a copyable request and source links.
What this does and does not establish
Passing these checks means the supplied URLs satisfy these local rules. It does not establish that a page exists, that a redirect stays on the approved host, or that your analytics account is recording events. Those require a separate authorized network check and a campaign-specific analytics test.
The value is a consistent preflight report that a person can act on. We have not measured recovered revenue, conversion improvements, or hours saved. To evaluate it in a team, compare the number of corrected links and review effort against the existing checklist. The workflow makes no external requests and has no provider API fee.