Should tracking pixel be placed at start of email for when Gmail clips messages?

With Mosaico templates, it isn't that difficult to reach Gmail's limit of 96-102kB with an email newsletter, after which your email message is clipped and not displayed in full. This is unfortunate in itself, but it also breaks open tracking as the tracking pixel is only embedded at the very end of the message and thus isn't fetched unless the reader clicks "View entire message".

Would it be worthwhile to consider putting the tracking pixel at the start of the message to avoid this issue? Obviously, less than ideal for those who don't display images, but I'm not sure how these two might balance out or if there is a clever way to have the best of both worlds.

I'd be happy to provide a patch, but not sure what the best way forward is here.

(Was a former Flexmailer issue, reposted here as I think this is still important.)

moved from mail#94 (moved)

changed the description

added comp:CiviMail type:proposal labels

Sounds good to me, @larssg. Would you mind putting this into a PR?

mentioned in issue mail#95 (moved)

@seamuslee, @artfulrobot, @tschuettler, @MikeyMJCO - you've all recently worked on mailing stuff, do you have an opinion on this, or know somebody who would?

So we currently add that at the end?

I think this is a good idea, as long as it doesn't end up affecting the 'preview' text extracted by some clients. It probably won't; <img> is not text (I'm guessing there's no ALT text?).

@artfulrobot Yes, the image is currently added to the end of the message, after the body and html tags.

It doesn't affect the preview text. There is about half a page of HTML and CSS before you get to the preview text for a Mosaico mailing. No alt text on the image.

I did a quick test and don't even see a little image icon in Gmail with images turned off, though you may in other clients (I have to imagine that people who have images turned off are probably not using Gmail, but they are a pretty small group anyways).

@larssg

I have to imagine that people who have images turned off are probably not using Gmail, but they are a pretty small group anyways)

I disagree. I mean, sure Gmail has huge section of the market on email accounts, but many mail clients disable images by default, and offer user-friendly ways for people to show images should they wish (e.g. show images button / always show images from this sender etc.). On mobile it makes sense not to load the images, for example, to conserve data/battery.

I realise I'm probably within the small group that you refer to anyway, but FWIW, I only load images if I think I'm missing out on some content (and occasionally I'll do it if I want the sender to know I've opened it). I have a Gmail account, amongst a dozen others!, but I don't access it via gmail.com; I have email client apps on my desktop and phone that do that. If you want to sent me an email (forums at artfulrobot dot uk) I can report if the clients I use show it incorrectly or not, though I am a minority user.

added triaged label

I don't have much experience with tracking pixels, but browsed through a few marketing mails in my inbox. Most tracking pixels seem to be at the bottom of the mail, but I have seen a version where it was added directly after an explicit pre-header. However I have no idea, how to add something like that without some bigger changes.

Adding it to the top would make it even more important that it is not visible. It looks like the pixel is still visible with for Outlook on Windows with enabled dark mode.

However, I'm quite confused why the tracking pixel (aswell as header and footer?) are outside of the body and even html tags. That does not feel right to me.

@tschuettler That does seem like a problem. I guess certain clients are going to show the transparent gif as white in some cases? Maybe it would help if it were inside html and body tags? That does seem to be standard from looking at emails in my inbox.

Unless things have changed since we switched over to Mosaico, I don't think traditional mailings even have html and body tags. Maybe they should be added and then we could move the tracking pixel above them?

I guess this one is more complicated than it appears. Could try to make this a setting or abandon the idea entirely. It does seem like bottom of message tracking is the default for most other systems. Perhaps running up against the Gmail length limit is not as common as I thought.

There's an issue with it being at the start - which is that clients will trigger the tracking when they render their preview, the image may be invisible but the HTML can still be executed. Though most clients won't try to load the image at all by default some will and having it at the start could introduce some inaccuracy.

Would it be overkill to track one image at the top and another image at the bottom? -- ie two different (but related) metrics.

Some systems do use both top and bottom tracking pixels, here's a discussion about what that enables as far as different tracking metrics. I think if we did that, we'd want to report on the two different metrics.

Hi,

Thank you for raising an issue to help improve CiviCRM. As you may know, this issue has not had any activity for quite some time, so we have closed it.

We would like you to help us to determine if this issue should be re-opened:

• If this issue was reporting a bug, can you attempt to reproduce it on a latest version of CiviCRM?
• If this issue was proposing a new feature, can you verify if the feature proposal is still relevant? Did it get the concept-approved label? Have other people also shown interest? Could it be implemented as an extension?

If the answer to either question is yes, please feel free to comment or re-open the issue. Please also consider:

• Is it something that you could help implement, either by sending a patch or hiring someone who can?
• Would you be willing to fund the work, either through a CiviCRM partner, or the Core Team?

Thank you for your help and contributions to CiviCRM.

P.S. This is an automated message, see infra/gitlab issue 20. We understand that automatic responses are annoying, but given the number of open issues as the project evolves, we need a bit of help to triage and prioritise the most relevant issues.

closed