Adestra

Building the mail and the journey around it: editor, templates, segmentation, triggered sequences, A/B testing.

0 — Not a campaign tool; mail cannot be composed and sent to a list from the product.

3 — Broadcasts to a list built in an editor with templates, with simple list or tag segmentation; automation and testing are basic or not described.

5 — A drag-and-drop editor with reusable templates, segmentation on subscriber fields or behaviour, automated sequences on common triggers (sign-up, date, click), and A/B testing of campaigns.

8 — A visual journey builder with branching on behaviour and data, dynamic content per segment, send-time optimisation, event triggers from shop or app data, and testing that reports significance rather than raw counts.

10 — Journeys treat the whole lifecycle: event-driven entry from other systems, branching on any attribute or event, holdout groups for measurement, and automations a marketer can read months later without a diagram.

Whether the mail arrives — authentication, sending reputation, bounce and complaint handling — judged on what the vendor documents rather than the inbox rate it advertises.

0 — The product does not send mail itself; delivery runs through the customer's own mail server with no sending infrastructure provided.

3 — Sending through the vendor's infrastructure with SPF and DKIM set-up for the sender's domain documented; bounce handling and reputation measures are basic or not described.

5 — SPF, DKIM and DMARC guidance with an authenticated custom sending domain, automatic suppression of hard bounces and complaints, and help-centre guidance on deliverability and list hygiene.

8 — Dedicated-IP options with a documented warm-up, seed or inbox-placement testing, engagement-based sunsetting, complaint feedback loops stated, and reputation reporting per sending domain.

10 — Deliverability is operated as a service: reputation monitoring surfaced to the customer, per-domain and per-ISP diagnostics, enforced authentication before first send, and postmaster or blocklist handling the vendor documents doing on the customer's behalf.

How subscribers arrive and what the sender can prove afterwards: double opt-in, logged consent, unsubscribe handling, and whether open and click tracking can be limited or switched off.

0 — Not built for consent at all: the vendor describes the list as imported addresses, with no sign-up forms and no opt-in confirmation in the product.

3 — Sign-up forms, double opt-in available and an unsubscribe link in every mail; the consent record and tracking controls are basic or not described.

5 — Double opt-in documented with a consent record per subscriber (timestamp and source), one-click unsubscribe, and open or click tracking that can be switched off.

8 — Consent is reproducible as evidence: double opt-in as the default, the confirmation mail and form wording stored per subscriber with IP, unsubscribe honoured across lists, a preference centre, tracking off by default available, and retention rules for inactive subscribers.

10 — Built for the burden of proof: a per-subscriber consent history an authority would accept, documented handling of Art. 15 access and Art. 17 erasure requests, pixel-free and link-tracking-free sending as a supported mode, and preference-centre granularity rather than all-or-nothing.

Whether the list and its history remain the sender's: import with attributes intact, full export including engagement history, deletion that executes, and no metering that prices leaving out of reach.

0 — The vendor states that the list cannot be exported; subscriber data stays inside the product.

3 — CSV import and export of subscribers with their fields; engagement history, unsubscribe state and deletion are basic or not described.

5 — Import with field mapping, subscriber export including custom fields and subscription or unsubscribe status, deletion of a subscriber on request, and an API to read and write the list.

8 — Everything exportable in open formats — subscribers, engagement history, campaigns and templates — with documented deletion of a subscriber across all records, and no export throttling.

10 — Exit is a documented feature: full-fidelity export of the whole account, contractual data return, deletion that is evidenced rather than asserted, and migration tooling in both directions.

The connection surface a newsletter lives on: shop and CRM systems, events in and out, webhooks, and an API somebody can build against without a partner agreement.

0 — A closed stand-alone tool: the vendor offers neither an API nor integrations, and the list is maintained by hand or CSV.

3 — A handful of named integrations or embeddable forms, or a basic API; webhooks and API documentation are basic or not described.

5 — Named integrations for common shop and CRM systems, a documented REST API with keys, and webhooks or connector-platform triggers for subscriber events.

8 — Maintained bidirectional integrations with named systems including at least one major shop platform, event webhooks with retries, documented rate limits, and a sandbox.

10 — The tool is a component rather than a destination: transactional and marketing sending on one API, events flowing both directions, versioned API with a deprecation policy, and integrations the vendor maintains rather than lists.

Where subscriber data and behavioural tracking live, who the contracting entity is, and which subprocessors touch the send. Independently sourced by the sovereignty pipeline; scored here as this buyer weighs it — which in this category is heavily. Dimensions not proven either way are unknown, not non-European.

0 — Vendor, contracting entity and hosting shown to be outside the EU, and no data processing agreement offered.

3 — A privacy policy and a data processing agreement exist and one European element is proven (an EU contracting entity or representative, or EU hosting as an option); the rest of the chain is not stated.

5 — An EU contracting entity and EU hosting stated, with a data processing agreement; sending, tracking or support providers are not all shown to be European or are named without a stated safeguard.

8 — EU or DACH hosting on named infrastructure, EU contracting entity, the subprocessor list published with locations including the sending infrastructure, and any non-EU processing named with its legal basis.

10 — Sovereign end to end and evidenced: vendor, entity, hosting, sending and every subprocessor in the EU, certification published, and no transfer that needs a Schrems II argument to survive.

Whether a sender can compute the real invoice for their list size and send volume — including overage, extra domains and automation limits — from public pages alone.

0 — No public prices at all; every tier is a sales conversation.

3 — A public "from" price, a free plan or one priced tier; how cost scales with contacts or sends is unclear.

5 — Prices per contact or send tier public for the main plans with the billing period stated and the main limits given; some add-ons (dedicated IP, extra domains, overage) may be unpriced.

8 — Every tier priced publicly with contact and volume limits, overage rates, feature boundaries and VAT treatment stated; only genuinely custom volume lacks a number.

10 — Complete price computability: a calculator producing the annual invoice for a given list size and send frequency, including overage, additional domains and dedicated IPs.