<signals>
With tracking done by the engine, it inserts a transparent image at the beginning of the message. The line lets you turn this part off. The default is yes.
There are three insertions in all, and each is enabled separately: link clicks, an image at the top of the message and an image at the bottom. By default all are on.
The image at the top fires more often: messages are often not read to the end.
🔴 It works only with engagement-tracking set to sparkpost. With external you send the events yourself, and the engine has nothing to insert.
Individual insertions are turned off rarely and for a specific reason:
| Value | When |
|---|---|
| yes (default) | tracking is on and needed in full |
| no | this particular insertion interferes with the layout or a policy |
# turning one insertion off, the other two keep working <signals> engagement-tracking sparkpost enable-top-open-pixel no</signals>
what people get wrong and how it ends1 mistake▶
our experience
1 relation
grep -i "signals" /var/log/pmta/log | tail -20
3 articles
◇Hand a message to a webhook instead of a receiverThe queue sends the message as a POST request in the form of a JSON object; only a 2xx response counts as success.◇The node can insert pixels and rewrite links by itselfIn the vendor’s tracking mode the engine parses outgoing HTML, rewrites links to the tracking domain and inserts open pixels — with a choice of what to do if the markup cannot be parsed.◇Markup parsing and editingOpen and click tracking in sparkpost mode edits the message markup with the built-in gumbo-parser; by default a message whose markup could not be parsed is bounced.