Hacker News Reader

Comment by kentonv | Hacker News Reader

The stated problem is with accounts that are inactive but still open. A gmail account that hasn't been touched in 10 years, for example.

View on HN

The way most people solve this is with a unique code attached to some tracking pixel that gets picked up when the HTML email is opened. We use an alternate of embedding the unique code in the links for the email so that even a text only email will trigger a click for that user if they copy/paste the link. You lose "open" tracking, but this isn't too bad unless you are selling ad impressions for your emails.

What about your subscribers which use text only email?

The links in the text email look like:

    https://www.example.com/foo/bar?blah_id=123456&utm...

If you don't copy/paste a link from any email within a year you end up falling off the "active users" segment and we stop wasting our time sending you emails. For text-only users (which we seem to have a few who have "clicks" but no "opens"). The particular system I work with is actually slightly more sophisticated and considers usage from a lot of channels (push message consumption, email opens and clicks, app usage, alexa usage, bot interactions, and website usage). If you don't do any of those things you fall into less and less frequent push/email interactions until we stop bothering with routine newsletter/updates messages except for an occasional "please come back"-style campaign.

I don't understand how copy/paste can trigger the tracking on your side. Can you please explain?

I am using mutt to read emails and vim to write them, I'd be very surprised if copy/paste has any effect for you.

The URL holds an unique id for each mail sent, such as the `blah_id=123456` example in the parent comment.

I understand that. I don't understand how copy/paste has anything to do with pinging anything on the internet with that code.

Is this maybe some gmail thing? I can't think of mechanism that makes copy/paste trigger this.

Copy pasting into the browser to view the link triggers this, just copying doesn't. If I understood the previous comment correctly, the author copies links into the browser instead of clicking them (since they aren't clickable links).

"Copy/paste" here means "Copy the URL, paste it into the address field of a Web user-agent program, and initiate navigation to that URL in that Web user-agent program".

I suspect the phrasing was used since the discussion is about text-only email and, this being Hacker News, someone might have nit-picked that they view plaintext emails in a mail user agent program which does not scan for strings matching the format of a URL and offer a direct way to click on them or otherwise trigger automated opening of them in a Web user-agent program, and so the person who wrote "copy/paste" had to avoid saying "click on the link".

And how many email users load images by default? How many of Mozilla's more technical demographic?

If I legitimately want emails from you (Mozilla seems likely) and you stop sending them, I'm going to be irritated. But if you stop because your phone home 1x1.gif doesn't load, that doesn't mean I wasn't reading them.

At least for my site, we consider multiple channels of engagement when calculating whether a user who is subscribed to something is active enough to bother messaging. If you don't click/open the emails (as far as our tracking can tell), but your account still opens our app, you'll keep on getting email updates until you unsubscribe via the unsub link, the profile preferences, or you close your account.

Mozilla is probably in a bit weirder position because their value-prop isn't in curating articles and videos the user is interested in. They don't require the users to login to use Firefox, and thus can't know if text-only users are using their emails unless they process unique ids on links inside the email (and that's the last step of the usual funnel, which means the segment definition is going to have to be really long (probably a year)).

I use MDN at least once a week, but I never log in. Hard for them to tell my email address is engaged.

Will that produce a bounce (and so.. graylisting/blacklisting)? I think not, but I may be wrong.

BTW the OP said "dead", not "inactive but still open"

No bounce. My reading of the article is that the problem is with accounts that are still valid, but inactive. If you send a lot of mail to such accounts, e-mail providers flag you as spammy, apparently.

So instead of making a fuss about broken anti-spam measures that are breaking email, mozilla gives in to tracking?

No. They proposed one way of handling it. People didn't like the proposal. They've come up with another way.

...which is remarkable because the email providers are the ones who are keeping the accounts open.

All they need to do is internally maintain a list of dormant accounts (as defined by not connecting to read email in some period of time); send a series of warnings to those accounts; stop accepting email for those accounts; at some point, delete the accounts and let mail bounce. Document the policy and the timeline.

What am I leaving out? Oh, forwarding accounts. Let the user mark them as forwarding accounts and change the "dead" heuristic to spot when all mail sent by the account's rules is bouncing.

I suppose that might cut the statistical boasting a bit (12 billion active users!) but at this point nobody has any sympathy for marketing departments anyway.

Email providers track "engagement", not just overall account activity. Plenty of "marketing" messages are sent to still active account and just go undread. Enough of this will cause messages to be routed to the bulk/spam folder.

That’s just one use case.

There’s a category of bulk mail that isn’t spam, but isn’t read. The providers punish those mailers who overload on those unread messages.

I doubt this explanation. I have personally seen spamhaus blacklist a newsletter that was subscribed to using double opt-in. What happened: the e-mails never bounced, the provider just closed down and - what a "coincidence" - the domain ended up being owned by someone who immediately used it as a "spam honeypot" for spamhaus.

It's apparently impossible to protect a sender against this by other means than detecting real user interaction. Alternatively, blacklist providers doing this could be ignored...

Reply on news.ycombinator.com