Mailwizz: campaign data into an operational summary

Joining bounce records with contact data

This completed project connected Mailwizz campaign data with a 26-column master spreadsheet. The task was to download bounce records, join them to existing contacts and prepare a summary by company, domain and address format. Separate registration data then enriched the report.

The processing chain

The brief used a rolling seven-day campaign window. Campaign identifiers were collected first, followed by each campaign’s bounce records. A CSV associated each email with the campaign name and a combined reason. The script matched addresses against the input sheet and populated bounce information.

A DOMAINS&MESSAGES tab held company, domain, format, status and message data. The summary grouped Hard, Internal and Soft bounces, delivered records, total attempts and delivery percentage. Rows disabled by status were excluded. Under the brief’s rules, a delivery rate of at least 60% for one address format disabled competing formats for the same company. Disabled addresses went to a blacklist with the reason “obsolete”.

Registration-log rows updated domain totals and were marked as processed. An unattended cloud schedule was requested, although the brief inconsistently mentions both a three-day cycle and daily execution; the published result does not resolve the final schedule. Likewise, “delivered” was a reporting assumption for records without a bounce, not independent proof of inbox delivery.

Reported delivery and processing time

The source explicitly marks the project complete and reports three days of work, three APIs, four folders, six files and 20 seconds for all operations. These are figures from my original account. Dataset size and environment were not recorded, so they cannot serve as a reproducible benchmark.

See spreadsheet automation, Python processing and Mailwizz API documentation. Discuss your data pipeline.

Historical source

The original project account marks the project complete. Its figures are historical, self-reported observations and should not be read as a current benchmark. The same brief also appeared under Node.js; it is one project, presented here once.