2 ms·

Awesome and very informative! Thanks for the explanation. I'm starting to get a better grip on this. I found a few posts online explaining how to do this with P

Awesome and very informative! Thanks for the explanation. I'm starting to get a better grip on this. I found a few posts online explaining how to do this with PHP and GD. In each of those instances, do you create a unique image for each user or each email?

dangrossman 11y ago
Let's say you assign each subscriber in your database a number. You send a mailing out to the list. In the mail to the first subscriber, you include this tag: <img src="http://www.example.com/track.php?id=1"> http://www.example.com/track.php?id=1"> In the mail to the second subscriber, you include this tag: <img src="http://www.example.com/track.php?id=2"> http://www.example.com/track.php?id=2"> And so on. There needs only be one file on your server to track opens no matter how many people you mailed: track.php. That one file reads the "id" parameter from the request to know which subscriber opened the mail, and logs that in your database. It then creates a 1x1 transparent image, in memory, using GD, and outputs that to the browser that loaded the image tag. The image never existed on disk, and nothing needed to be created in advance of sending a mail.
- atomical 11y ago
  GD seems like overkill if the same 1x1 pixel is being generated over and over again.
  - davismwfl 11y ago
    As a point, at least in my implementation, I actually use a byte stream for the 1x1 that is cached and sent to the browser. We do this so that there is no disk read ever for it. We also don't use php/gd, our code is mostly node.js and a little golang with nginx as our front end. It may seem a little overkill, but I found doing it this way made a pretty significant impact when you have a reasonably decent volume of tracking going on. A good http server of course would cache the image of course, but we just found this to be easier and more consistent for our implementation.
davismwfl 11y ago
Your welcome. dangrossman answered this in detail already and I agree with what he says. Just as an example, in my system each email that gets sent out has a unique id (in our case a hashed id), we use that as the id value. From there we can get back to campaign, email address, company etc. As for the image itself, it is physically only one image generally (or an image byte stream cached in RAM). btw -- dangrossman used sequential numbers as the ID only as an example to show you, you wouldn't do that in a production system. Have fun!

dangrossman 11y ago

Let's say you assign each subscriber in your database a number. You send a mailing out to the list. In the mail to the first subscriber, you include this tag: <img src="http://www.example.com/track.php?id=1"> http://www.example.com/track.php?id=1"> In the mail to the second subscriber, you include this tag: <img src="http://www.example.com/track.php?id=2"> http://www.example.com/track.php?id=2"> And so on. There needs only be one file on your server to track opens no matter how many people you mailed: track.php. That one file reads the "id" parameter from the request to know which subscriber opened the mail, and logs that in your database. It then creates a 1x1 transparent image, in memory, using GD, and outputs that to the browser that loaded the image tag. The image never existed on disk, and nothing needed to be created in advance of sending a mail.

atomical 11y ago
GD seems like overkill if the same 1x1 pixel is being generated over and over again.
- davismwfl 11y ago
  As a point, at least in my implementation, I actually use a byte stream for the 1x1 that is cached and sent to the browser. We do this so that there is no disk read ever for it. We also don't use php/gd, our code is mostly node.js and a little golang with nginx as our front end. It may seem a little overkill, but I found doing it this way made a pretty significant impact when you have a reasonably decent volume of tracking going on. A good http server of course would cache the image of course, but we just found this to be easier and more consistent for our implementation.

davismwfl 11y ago

Your welcome. dangrossman answered this in detail already and I agree with what he says. Just as an example, in my system each email that gets sent out has a unique id (in our case a hashed id), we use that as the id value. From there we can get back to campaign, email address, company etc. As for the image itself, it is physically only one image generally (or an image byte stream cached in RAM). btw -- dangrossman used sequential numbers as the ID only as an example to show you, you wouldn't do that in a production system. Have fun!