Why a website subscription loses emails: analyzing Unisender integration
A subscription form on a website looks functional: field, button, “thank you, you are subscribed” message. The request, however, may go nowhere — the handler puts the address into a local table or sends an email to a manager’s mailbox, while nothing reaches the email service.
A month later, it turns out that half of the collected base is sitting in a file no one has processed, and those people have not received a single email.
Second typical failure — loss of double opt-in subscription statuses. A person receives the email, clicks the button, but the service’s response is not saved: in the database they remain unconfirmed, and confirmation requests are sent again and again.
The recipient perceives this as spam and complains — complaints and unsubscribes directly hurt email deliverability for the entire base, not just one address.
Third — flawed error handling. If the service returns a rejection or responds with a delay, the handler does not retry the request and does not log the failure, but simply loses the address.
Resubmitting the form adds the same person a second time, emails go to addresses no one confirmed — and part of the base goes into unsubscribes through our fault.
Loss of subscribers is almost invisible in the interface: everything is “successful” there until you compare the number of website requests with the number of new addresses in the service.
Unisender integration must close exactly these gaps — the request arrives and gets a status, a repeated request does not duplicate the address, and a failure is visible in the log rather than in someone else’s mailbox.
What changes after setup: deliverability, speed, unsubscribes
While contacts enter the base via a file export once a day, a person who subscribes in the evening receives a welcome email the next day — and by that time some addresses no longer remember where they gave consent.
After connecting the website to Unisender, the contact goes into the base at the moment the form is submitted, together with the subscription status: confirmed, pending confirmation, unsubscribed.
The email arrives within a minute, while interest is fresh, and statuses sync in both directions — an unsubscribe on the website stops the mailing, an unsubscribe in an email is visible on the website.
The share of confirmed addresses grows due to double opt-in: an address enters the active base only after clicking the link in the email. This filters out typos, foreign and role addresses, and the mailing goes to those who actually expect emails.
Reduced unsubscribes and spam complaints are a consequence of the same order.
One-click unsubscribe immediately changes the status both on the website and in the mailing base, so there is no need to look for the “this is spam” button: emails are not sent to unsubscribed contacts, and email filters see that the unsubscribe mechanism works. The share of messages landing in the “Inbox” grows along with engagement.
The effect is measured by four numbers: time from form submission to the first email, share of confirmed addresses, share of unsubscribes, and complaint rate.
It is worth checking them once a month: if confirmed addresses have decreased, the form or the email text has stopped explaining why to subscribe.
Connection methods: ready-made form, script, data exchange
Connection methods differ not by “level of complexity” but by where the source of subscriber data lives.
In one case, the address is collected directly on the page; in another, it comes from the server together with an order or registration; in a third, it goes back when a person unsubscribes. This determines the requirements for the website and the limitations that will appear later.
In practice, the methods are not replaced but combined: one receives addresses, another synchronizes statuses. The table shows four options, when each is appropriate, and what it cannot do.
| Method | When it fits | Limitations |
|---|---|---|
| Built-in subscription form | Landing page, blog, promo page: collecting addresses without modifying the website | Fields and design are set by the template; connection to an order is configured separately |
| Subscription script | Multiple points on the website, pop-up window, form inside content | Checks run in the browser: if third-party scripts are blocked, the form will not appear |
| Programmatic data exchange interface | Subscription as part of registration, order, export from an accounting system | Requires server-side handling of responses and retries: on failure, the contact is lost |
| Event notifications | Reverse synchronization: unsubscribes, complaints, undelivered emails | Requires an event receiver and protection against repeated processing |
More often a combination is chosen: a form or script on the storefront, data exchange for the personal account and accounting system.
When connecting to Unisender, we record which process each channel closes and assemble a minimal configuration: the list is not duplicated, unsubscribes reach the website.
Stages of Unisender integration implementation: from audit to handover
The order here is not a formality: if you first set up the mailing and then sort out contact sources, unsubscribes and duplicates surface after the first sends — and the domain’s reputation is already damaged.
Therefore, we follow the stages of Unisender integration implementation from audit to handover, fixing a verifiable result at each step.
-
Audit of subscription forms and the current scheme. We look at where contacts come from, which list they are written to, whether subscription confirmation exists, how unsubscribes and repeat registrations of the same addresses are handled.
-
Data flow scheme. We draw a map: form field → custom field → list, segment, or tag → scenario. Here we also define deduplication rules by address and value normalization so a person does not end up in the base three times.
-
Setting up the connection. We create lists, segments, tags, custom fields, and templates, issue access keys, and connect events from the website: registration, order, abandoned cart.
-
Testing mailing scenarios. We run the chains on test contacts — welcome email, warm-up series, order notifications. Separately, we check unsubscribe, resubscription, and behavior when the service is unavailable: events should go to the queue, not be lost.
-
Data reconciliation. We make sure that an unsubscribe on the website removes the contact from the mailing, and a status change in the service is reflected in the website database.
-
Handover of access. We hand over accounts and keys, the flow scheme, the policy for adding new forms and scenarios, and the procedure for troubleshooting errors.
Configuration, schemes, and policies: what remains with the client
Handing over the integration is not only working scenarios but also a set of artifacts your team can use to change mailings without us. Below is what remains in your hands after launching the integration of the email service with the website.
- Scenario map. All chains on one scheme: website event, condition, delay, email, next step. It shows where scenarios intersect and where they conflict for the same audience.
- Email templates. Welcome, triggered, reactivation, and service emails — with subject line, layout, and a list of variables. It is marked which blocks the editor can change freely and which are tied to website data.
- Subscriber field setup. Which fields are required and service, what they are called on the website and in the service, and rules for normalizing phone and email with duplicates and empty values.
- Access policies. Roles in the service: who sees lists, who edits templates, who only exports statistics. Separately — permissions for programmatic keys and the procedure for replacing them.
- Instructions for the mailing editor. Step-by-step email assembly, variable checking, test send to your group, procedure for publishing and rolling back an unsuccessful version.
- Synchronization and unsubscribe policy. Exchange frequency, behavior when the website is unavailable, event retries from the queue, and accounting for complaints and delivery failures.
Every artifact is checked against a live scenario: subscription, branching, sending, unsubscribe. Everything remains in your repository and in the email service — you can change scenarios and texts without our involvement.
Case study: how the base of confirmed subscriptions grew
In an online store, subscription relied on manual contact export: a manager once a week exported requests from the admin panel, cleaned the list by eye, and uploaded the file to the email service.
By the time the task was analyzed, up to a third of addresses were duplicated — a customer came through the form, chat, and offline point of sale — and emails were also sent to unconfirmed addresses, which caused the domain to lose reputation.
We connected the website to Unisender directly: the subscription form writes the contact to the right list at the moment of submission, with source and date, and immediately enables address confirmation.
Deduplication runs by normalized address on every write, the welcome triggered chain starts after confirmation, and unsubscribes are synchronously returned to the website so a person is not subscribed again.
Metrics before and after
| Indicator | Before integration | After |
|---|---|---|
| Share of confirmed addresses | 41% | 88% |
| Duplicates in the base | about 30% | less than 1% |
| Delay between subscription and first email | 3–7 days | minutes |
| Manual operations with the base | 4–6 hours per week | not required |
| Unsubscribes after the welcome series | 9% | 3% |
There are no manual operations with the base left, and every contact has a source and date — interest-based segmentation can be built without exports.
Such an email integration case gives subscriber base growth not through volume but through quality: you can write more often and more safely for the domain’s reputation.
How do transactional emails differ from bulk mailings?
A transactional email is a reaction to a person’s action: order confirmation, receipt, access recovery, login code. It cannot be delayed — the recipient expects the email that same second and cannot complete the scenario without it.
A bulk mailing works differently: it can be spread over hours, divided by segments, and sent when the audience is active.
Hence the separation of email streams. In a shared stream, a confirmation code queues behind a campaign to hundreds of thousands of addresses, and the customer receives it forty minutes later.
Delivery priority is solved by separate connections and separate queues: a transaction goes out immediately, a bulk mailing goes in the background, with a sending rate limit.
Template requirements also diverge. In transactional email, precise variable substitution matters — order number, cart contents, one-time link — and consistent layout across all email clients.
In bulk email, the template carries the brand and block sets for segments, while personalization is limited to the name and a couple of fields.
Handling sending errors is the main difference. An address rejection in the transactional stream means the person did not receive a receipt or could not log in: retries with increasing delay, a failure log, and a signal to support are needed.
In a bulk mailing, a hard rejection is a reason to mark the address inactive and exclude it from future sends, not to repeat the send endlessly.
And domain reputation: mixing streams with different complaint rates is risky. A spike in complaints about an advertising campaign will drag down the deliverability of receipts and codes.
In Unisender, this is separated at the level of connections and limits — each stream has its own statistics and its own reactions to errors.
Common technical questions: synchronization, duplicates, failures
When integrating a subscription form with an external email service, teams run into the same places: duplicate contacts, form behavior when the external service is unavailable, and confirmation of user consent.
These are not interface settings but decisions at the level of the data scheme and handlers — so we address them before the start, not after the first complaint about a mailing.
Below are answers to technical doubts that most often come from engineering teams: how contact matching is calculated when merging subscriber bases, what the user sees when the service side fails, and what confirms consent to data processing.
How to avoid duplicate contacts when merging subscriber bases?
Matching is calculated by normalized address: we convert to lowercase, discard dots and aliases such as “plus-tag.” The address becomes the matching key, the remaining fields are merged by a priority rule — a fresher value overrides an older one, conflicts are written to the log with the source.
Duplicates are not deleted silently: the merge is recorded so that attributes are not lost during the next synchronization.
What happens to the form if the external service is unavailable?
The form does not drop the request into the void and does not show the user an error. Data is written to a local subscription table and queued for sending; retries occur with increasing delay, and the contact state is synchronized when the service responds.
The user sees confirmation immediately, and the subscription reaches the external service without their involvement.
How is resubscription after unsubscribe confirmed?
We keep the contact status in a separate field rather than deleting the record — so the history of unsubscribes and resubscriptions is preserved.
Resubscription removes the refusal mark but does not resurrect old segments: the contact is included only in the mailings they are subscribed to now, and passes confirmation via email.
How is consent to data processing stored?
We record consent on our side: time, version text, form source, and the page from which the request came. A mark in the email service does not replace this — it lives there and disappears with the contact. The proof remains on our side and is exported on request.
Let's discuss the task: what is needed for an estimate and work plan
The estimate for integration depends not on mailing volume but on how many points on the website generate events and how predictable the current state of the contact base is.
Below are project inputs sufficient to calculate the scope of work and come back with an implementation plan. If something is not at hand, we will start with what is available and clarify the rest during the analysis.
- Subscription points: forms in the footer and on landing pages, pop-up window, registration step, checkout — and what exactly is recorded as consent.
- Trigger scenarios: which event launches an email, how many minutes after it, what happens on repeated triggering, and how the scenario stops.
- Access: Unisender account with permissions to create scenarios and an API key, website admin panel, domain zone for setting up email signatures.
- Website platform and its limitations: how events are provided, whether there is a queue for delayed sends, how the website handles peak load.
- Base state: contact fields, tags and segments, duplicates, subscription and unsubscribe history, share of invalid addresses.
- External systems: CRM, warehouse, payments — which of them serves as the source of truth and which only supplements segments.
- Requirements for personal data storage and the period for which consent to mailing is taken.
This set is enough to estimate the work and prepare for the start. We will go over disputed points on a short call and clarify the rest in correspondence. Describe the task — we will come back with a timeline estimate and a stage-by-stage implementation plan.
