An Email Marketing Platform Supplies Two Functions of Different Kinds in One

Look into email marketing platforms and a comparison table appears. Deliverability, measurement, automated sequences, supported list size, price. Vendor names run down the side, items run across the top, and the cells are filled with circles, triangles and crosses.

The comparison holds. Feature lists are published, so lining them up produces differences. Differences appear, so all that remains is to pick the column matching your own conditions.

Yet you can read that table top to bottom and still not settle. Everything is adequate and nothing is decisive. The items where differences do appear none of them look conclusive.

The decisive thing is missing from the table because the table shares one premise. The list of contacts is treated as something held inside whichever platform you choose. Where it is held has not become a question at all; only which platform to choose has.

A delivery platform supplies two functions of different kinds at once. One is storing contacts, the other is sending mail. Technically they are separate, and they can in fact be separated. Leave them joined and every change of sending mechanism drags the stored contacts along. Contacts shrink when moved.

Three things get solved. First, what each of the two functions inside one platform actually is. Second, what actually settles the deliverability that everyone rates most highly. Third, what divides outcomes among platforms that share a sending origin.

One question stays open. Which vendor you ought to choose is not decided here. Selection turns on volume sent, the nature of the content, and the relations among contracts you already hold, so an answer produced without seeing those conditions misses. What can be handed over here reaches as far as a design that makes selection lighter.

With the two functions joined, the judgement to change platform becomes the same judgement as moving the contacts. Become the same and the judgement grows heavy. Dissatisfied with a feature, you weigh the labour and hazard of moving and stay. Staying, the dissatisfaction persists unresolved. And while deferral runs, the list keeps growing, so the judgement grows heavier still. The earliest choice is the lightest one, and it is made at the point of least information — that is the order sitting here.

And the process of growing heavy does not show in the numbers. The list grows, delivery arrives, the price is unchanged. What has changed is the difficulty of leaving. What follows is arranged as a route to making that difficulty of leaving lighter.

The five axes lined up for comparing email delivery systems are all looking at the same place

The method of choosing in circulation is organised into five axes. And all five look only at the inside of the platform.

An email marketing platform is a dedicated mechanism for sending mail to many recipients at once. Sending in bulk from ordinary mail software produces failures to arrive, treatment as junk, and mistaken display of recipient addresses, so a dedicated mechanism gets used.

A distinction in naming is also presented. The mechanism used by individuals and small operators is called a delivery stand, while enterprise mechanisms handling large volumes are called mail delivery systems. The list sizes handled and the breadth of features differ.

Five observation points are typically raised for choosing. Rate of arrival, whether effects can be measured, whether other mechanisms connect, list size handled, and price.

Rate of arrival is presented as the item to rate most highly, on the ground that however good the content, it means nothing undelivered.

On features, whether opens and clicks can be measured, whether recipients can be narrowed by condition, and whether messages can be sent automatically in a fixed order.

Choosing by purpose is also set out. Aiming at purchase, take one strong on measurement; aiming at deepening a relationship, one where appearance is easy to build; holding costs down, one with a free tier. And a comparison table of named services with a ranking occupies the middle of most articles.

Every item here is sound as an observation of practice. A dedicated mechanism is genuinely required, and the feature inventory is comprehensive. Nor is the point about rate of arrival off the mark.

None of that being in dispute, take out the premise the five axes share. What is being measured is in every case a capability the platform holds. Volume sendable, items measurable, destinations connectable. Nothing outside the platform has entered any axis.

None of which is unnatural. What is being compared is platforms, so lining up platform capabilities follows. Most platforms do supply storage and delivery joined, and that is easier to use.

The trouble is that lining up only capabilities drops out of the table whatever is not settled by capability. Rate of arrival is the leading case: it is not settled by platform capability. Where the contacts are held drops out too, because a location is not a feature.

And the two that dropped out are both items that grow heavier with time. Items on the table can be swapped by changing contract; the two that dropped out cannot be swapped. The more diligently the table gets read, the further back the judgement on the unswappable side gets pushed.

Storage and delivery are two functions of different kinds

The function of storing contacts and the function of sending mail differ in nature: one accumulates, the other is exchanged.

The storage side records who registered when and whether they presently intend to receive. The delivery side gets written wording to the stored addresses.

The two differ wholly in kind. Storage is a function that accumulates. It grows with time, and what has grown becomes an asset of the business. And lost, it cannot be recovered.

Delivery is a function that executes. It completes at each use and accumulates nothing. Exchanged for another, nothing is lost.

Putting what accumulates and what gets exchanged in the same place is the problem. This has the general shape of a question about locations. What piles up goes in a place that is hard to move; what gets exchanged goes in a place that is easy to move. Reverse them and each exchange drags the accumulation.

So the design runs: hold the list of contacts near at hand, and treat the delivery mechanism as exchangeable.

Near at hand means a copy under your own control, in a format readable outside that platform. Both the list inside the platform and the copy at hand may exist. A state where only one exists is the problem.

The worry that holding two copies will let them diverge is correct. They diverge. The copy at hand is as of the moment it was extracted.

Divergence is not a problem for this use. The office of the copy at hand is not daily delivery but recovery when the platform is lost. With a copy from a month ago, everything but a month’s difference recovers. Against having nothing at all, the outcome is wholly different.

Holding a copy carries a duty of handling. Contacts are personal information, so the location and the rules of management have to be settled.

That duty is arising equally when everything sits inside the platform. It is merely harder to see. Held at hand, the duty takes a visible form. Becoming visible is not in itself bad.

Near at hand does not mean a place you open daily. What is used infrequently has a manner of storage matching that frequency. Two things are required. That it stays readable if the platform is lost. That you can explain the location and the rules of handling yourself. With those two met, the format does not matter.

This division also changes the selection itself. Joined, what you are choosing is somewhere to entrust this to from now on. Divided, what you are choosing shrinks to a means of sending at present. Looking at the same comparison table, the question being read is different.

What settles the rate of arrival is not platform capability but the history of the sending origin

The item rated most highly is settled outside the platform. What adjudicates whether mail enters the inbox or gets filed as junk is the receiving provider. Not the sending platform.

What the adjudication draws on is chiefly the history of the sending origin. Of the mail previously sent from that origin, how much was opened, how much was reported as junk, how much went to addresses that do not exist. What is being adjudicated is the record of the origin’s conduct.

Two things come out of this. First, changing to a better platform does not raise the rate of arrival straight away. History is bound to the origin, and history takes time to accumulate.

Second, the main means of raising the rate of arrival lie outside the platform. Stop sending to addresses that do not exist. Stop sending to those with no intention of receiving. Send content that gets opened. Each of these is a matter of your own operation.

This structure has the same shape as what settles whether mail gets opened. A factor outside the wording settles the effect of the wording in advance. The detail is handled in writing a newsletter and what the open rate really is.

None of this says platform capability is irrelevant. Whether the origin’s authentication can be configured correctly, whether junk reports are detected and excluded automatically — such features prevent the history from worsening.

But they are features for not worsening the history, not for improving it. They hold the floor; they do not raise the ceiling. The deliverability column on a comparison table does not make that distinction.

Deliverability figures published by vendors make poor material for comparison, because what was used as the denominator and what counted as delivered often go unpublished.

And part of a high figure comes from strict vetting of senders. Keep poor senders out and the aggregate rises. In that case a high figure is a benefit you receive and, at the same time, the strictness by which you will be vetted.

Once it is clear that arrival is settled by operation, the writing of content is affected too, because continuing to send unopened mail lowers later arrival.

A pressure arises here that nobody intended. The pressure by which content drifts toward provocation, from prioritising being opened. It arises naturally out of the mechanism. Resisting it means taking a different measure: removing unopening recipients from the sending set. Excluding those who are not receiving is not a discarding but also a consideration for those who do receive.

Where the sending origin is shared, what settles the outcome is the presence of discipline

On many platforms, several users share one sending origin. A dedicated origin is normally supplied only on higher contracts. Sharing means the conduct of everyone sending from that origin composes a single history.

If another user sends in bulk to those with no intention of receiving, that history returns to everyone sharing it. However carefully you operate.

This structure has long been discussed as the problem of a shared resource. Hardin set out a figure in which each party adding livestock to a shared pasture acts rationally in individual judgement while the pasture as a whole degrades (Hardin, 1968, Science, 162(3859), 1243–1248).

That argument carries an important qualification, though. Ostrom pointed out that Hardin had not distinguished a state anyone may freely enter from a state managed in common under discipline (Ostrom, Governing the Commons, Cambridge University Press, 1990). She set out cases from many regions where resources managed in common were sustained over long periods.

Put onto delivery, this reads: sharing a sending origin does not in itself mean the history worsens. What settles it is whether discipline is present there.

What corresponds to discipline is the vetting of senders and the response to breaches of terms. On a platform where anyone can register and poor sending goes unaddressed, the shared history worsens. On a platform with vetting and a response to breaches, it is sustained even while shared.

So what has to be confirmed is not shared or dedicated. It is whether vetting exists.

And that confirmation shows in the registration procedure. A platform where you can begin sending without being asked anything is not vetting. A platform that confirms your use and how you obtained your recipients is vetting. Registration being troublesome is, in this context, a good sign.

A platform that vets will vet you too. Unable to explain how you obtained your recipients, you cannot use it. Being unable to explain is a problem of operation in the first place. Which means the vetting also serves as an occasion to inspect your own operation. Confirming for yourself, before registering, whether you can explain it makes the judgement faster.

Besides the registration procedure, there are two ways to confirm discipline from outside. One is how concretely the terms set out prohibitions. Terms stating no more than a prohibition on nuisance conduct are likely not being enforced. Terms that go as far as how recipients were obtained and how consent was taken hold a standard of operation.

The other is whether the handling of junk reports is written down. A platform holding a mechanism that excludes automatically on report has a mechanism working against the worsening of history.

Put the contact list that accumulates at hand and the delivery system that gets exchanged outside

The design fits in one line: hold storage and delivery separately. What that means in practice divides into three.

The first is extracting the list periodically. Output it in a standard format and save it at hand. Whether extraction works cannot be known without doing it once.

The second is putting the registration entrance on your own side. Rely on a screen supplied by the delivery mechanism as the receiver for registration and changing platform means rebuilding the entrance too. Pass from an entrance placed in your own location to the delivery mechanism and only the destination gets swapped.

The third is keeping settings that run only on that platform to a minimum. The order of automated sequences, the conditions for narrowing, formatting. These do not move, so record externally what was configured and how.

All three have the same shape as the three handled in how to choose a web host. The same principle is landing on a different object. The principle can be said as one: put what accumulates and what gets exchanged in different places.

The worry that placing the entrance on your own side increases configuration work is correct. It increases. Using the supplied screen as it stands is faster.

The increase is once only. And having paid it, the judgement to change platform grows lighter. A lightened judgement is one you can actually use when conditions worsen. Unpaid, you stay even as conditions worsen.

Placing the entrance on your own side can add one step before registration completes. Add a step and some drop out partway.

That loss can be measured. Compare arrivals at the entrance with completions of registration. Having measured, if it is too large, work at reducing the steps. Settle the design by estimating that more steps will mean fewer without measuring, and you write off as lost what you never lost.

Only the first of the three is repeated work. The second and third finish once, but extraction of the list goes stale each time the list grows.

Repeated work gets forgotten. Not forgetting means either fixing a time to do it or holding a mechanism that leaves a copy automatically. That judgement is itself an instance of the general rule that only what has finished being decided can be automated. Without settling the frequency of extraction, it cannot be automated either.

The abundance of features is itself the cost of moving

Having many features itself creates a cost of moving. The more features in use, the more there is to rebuild wherever you move to.

That relation looks reversed on a comparison table. The platform with more features looks superior on the page.

Both are true. Having many features is a gain in daily operation and a cost at the moment of moving. So the judgement is not many or few but which features get used. Unused features produce no gain and only raise the price.

And among the features used, whichever are saved in that platform’s proprietary format are the substance of the moving cost.

Split out concretely: the order of an automated sequence can be rebuilt if recorded externally. Narrowing conditions likewise. Formatting moves if written in standard notation, but what was assembled in a proprietary editor does not.

The more that gets built in unmovable form, the higher the cost. And that accumulation advances naturally within daily operation.

It goes unnoticed because the unit of increase is small. The increment from adding one setting is below the threshold of awareness. Only the accumulated total appears, all at once, on the day you try to move.

Not using features to lower the cost inverts the point. Features are what the contract is for. What can be lowered is lowered by record. Write the settings you used externally and, even saved in an unmovable format, they can be rebuilt. The substance of the cost lies not in the format but in losing track of what was configured.

Records go stale each time a setting changes. Unupdated, they disagree on the day of the move. To lower the burden, record not the value of the setting but the reason it was placed. Values change; reasons rarely do. With the reason known, the value can be re-settled wherever you move to.

Choosing a platform with few features so the problem never arises is also a viable solution. It becomes less likely, though with few features manual work remains on the operational side.

Manual work creates no moving cost but consumes daily time. What settles which to take is the frequency of the work. Monthly work can stay manual; work occurring every time is worth handing to a feature. Cut by frequency and the necessity of a feature becomes something you can adjudicate yourself.

That cut has a secondary effect. Counting frequency requires knowing how often the work occurs. Counted, the result is frequently that work you were trying to solve with a feature was not occurring even monthly. The contents of a contract are often less an inventory of features used than an inventory of work you imagined would occur.

Of the three restrictions in the free tier, only one bears on history

Many platforms provide a tier free up to a certain list size. It lowers the burden of starting, so it is a sound option. What has to be confirmed is what that tier restricts. Restrictions come in roughly three kinds.

The first is list size and send count. This is plain and published.

The second is features. Automated sequences and narrowing are sometimes available only on paid tiers. A feature unused at the outset may require raising the tier later.

The third is a restriction on your own display. The vendor’s name appended to the message, or an inability to configure your own sending origin.

Of these, only the third bears on history. On a tier where you cannot configure your own origin, the origin’s history cannot accumulate on your side. Not accumulating means that whether you raise the tier or change platform, the history begins from zero.

So even using the free tier, whether your own sending origin can be configured is worth confirming.

The judgement that at the very start you send too little to accumulate history, so it can be considered later, is also available. While the list is small, the effect is indeed small.

But change the configuration later and history begins from there. Configure it early and it accumulates from the stage where the list is small. And the small-list stage is also the stage where mistakes matter least. As a place to learn, that is the safer one.

Configuring your own sending origin requires configuration on the address side. At a stage where you do not hold your own address, it cannot be configured at all. Which means this item depends on the judgement to hold an address. In order, the address comes first.

None of this says the free tier should be avoided. While the list is small, being able to start without cost has value.

What to confirm is what carries over when moving to the tier above. Raising the tier within the same vendor normally carries over. What does not carry over is moving to a different vendor. Which means the free tier puts you at no disadvantage for as long as you stay with that vendor. The disadvantage arrives when you decide not to stay.

And whether you will stay cannot be settled at the point of starting. Being unsettleable, choosing on the basis of free is in substance choosing on the premise that you will stay. Holding a premise is fine in itself, but it is worth being aware you have held one. Confirm the third item first and the premise need not be held at all.

The reputation of the sending origin also accumulates on the side of your own name

Two things accumulate in this domain. One is the list of contacts, the other the history of the sending origin.

The list of contacts is visible. Countable as a number, it gets recognised as an asset.

The history of the sending origin is not visible. Displayed as no figure, it is hard to recognise as an asset. And yet it is what settles whether mail arrives.

And where the history accumulates is the address of the sending origin. Not the delivery mechanism. With your own address as the origin, the history remains through a change of platform.

So the design of this domain can be said in one principle. Put what accumulates on the side of your own name. The list of contacts, as a copy at hand. The history of the origin, as your own address. Both are held independently of the delivery mechanism.

Adopt this design and the delivery mechanism becomes genuinely exchangeable. Exchange it and nothing accumulated is lost.

And once it is exchangeable, the way of choosing changes as well. With no need to consider whether it can be used indefinitely, you can choose on the features required now. The choice grows light. Much of the work of poring over comparison tables comes from the absence of that lightness.

The history of the origin does not accumulate only when it is good. Bad history accumulates at the same address. So this design comes paired with discipline in operation. Send indiscriminately and bad history accumulates at your own address. Using a shared origin, bad history is dispersed — and good history does not become yours either.

With your own address as the origin, the reputation of that address becomes one thing. Where the site address and the mail origin are the same, a problem on one side can affect both. A design that separates them exists: using a dedicated subordinate name for delivery separates the effect. Whether to separate turns on volume sent and the nature of the content.

One more thing appears in the interval before history accumulates. An origin just configured holds no history. An origin with no history has been adjudicated neither well nor badly, so it gets handled cautiously.

So immediately after switching, the rate of arrival can fall for a time. Panic here and revert, and the accumulation of history returns to the start. If you are going to switch, doing it while the list is small and a fall matters little is the reasonable course. This too is among the operations that are cheaper earlier.

Supposing the delivery system you use now stopped tomorrow, what would remain at hand

Whether the two functions are separated reads off three moves. Not one of them counts features. Separation is not a property of features, so what gets looked at is the side of the bindings.

Suppose, first, that the platform now in use stopped tomorrow and write out what would remain at hand. Does the list of contacts remain. Does the record of who registered when remain. Are the automated sequence settings knowable. Anything that would not remain marks a place that is not separated.

The second is to actually extract the list. Being written as extractable and actually extracting are different. Format, number of fields, handling of characters. Some things are known only by doing it.

The third is to look at the sending origin configuration and see whether it is your own address. Left as the vendor’s origin, the history is not accumulating on your side. This confirmation shows in the details of any sent message.

The three have limits. All of them work only where operation has already begun. At the stage of choosing, you read the published extraction procedure and whether your own sending origin is supported.

A platform not publishing those two is itself information. Extraction and origin configuration are items with no reason to conceal.

The judgement that with a handful of subscribers this level of confirmation is unnecessary is also available. The cost of confirming is at its lowest now. With a small list, both extraction and configuration finish in an instant. And installing this design later is heavy: rebuilding the entrance, changing the origin, accumulating the history again. Getting it done while the need is small is the cheapest order.

No answer here can be handed over as a ranking. Which vendor to choose does not have the shape of a question answered by resorting a comparison table. It is settled by volume sent, the nature of the content, and the relations among contracts already held. A ceiling on price and a count of features have the same shape.

The answer to which one to choose is not found in the table because the table lines up only platform capabilities. The decisive things sit outside the platform. What settles the rate of arrival is the history of the origin, and history accumulates at an address. Contacts are what accumulates; delivery is what gets exchanged. What divides outcomes on a shared origin is the presence of discipline.

Two things to do today. Suppose the platform under contract stopped tomorrow and write out what would remain at hand. And run the extraction of the list, once. Both come cheaper the smaller the list.

The design of what gets sent is in how to write an email sequence, and the upstream thinking on how to hold a list is in the premises of list building. A decider sitting outside the machinery’s specifications is not confined to this one case. That what is short, when a system will not come together, is not technique is set out in implementation and automation as a whole.