Chad

@andrewatfornax. Good point about multiple devices, AND thank you for taking the time to have this dialog with me. I truly appreciate it. I think I should take a step back to see how you'd propose I solve my need? Here's more details. I don't send many actual email campaigns. I have a forum that sends email notifications. I'd like to include 3-4 small sponsor logo banners in the email footer to recognize their support. When the email goes out I'd like all sponsors to have an equal probability of exposure. It's fine if the same user/device sees the same banners every time they view the email. What's important is that the sponsors are getting equal love from the community. I'm seeing an email zone per advertiser being my logical fallback (as you proposed in your original response.) My notification system can then randomly select the advertiser-specific email zones. I do worry about duplication of logic (ex. advertiser campaign durations) and how I manage that. I definitely don't want APIs calls to revive in my notification code (at least not one per email notification.) I didn't find much on direct selection in the docs. Do you have any recommendations on: alternative approaches (perhaps a custom plugin) managing duplication of logic in the zone-per-advertiser approach details on direct selection approach (best I understand it is I add a keyword to the banner, not sure how to create the invocation tag) or am I just heading down a dead end I definitely don't expect you to solve my problem for me. You're the expert, so I'm hoping you can point me in the right direction. Many thanks!

Thank you for the response, @andrewatfornax My thought is that since I'm already using PHP to generate a random number for the CB argument, I could do the same thing for a correlation identifier argument. Yes, each email would have its own CI, but generating those would be as simple as creating a GUID or large random number. Those identifiers wouldn't need to be tracked by the ad server until the banner is served. When we log the impression, we would also temporarily cache the CI. When the banner is clicked, we look up the banner ID using the CI. And the cache self trims with time. If someone is going to click that Banner, I imagine it would be within minutes or an hour of the impression, so the cache items should not need to hang around too long. This hopefully reduces scalability issues unless you get hit with a massive amount of email reads at once. Even then, we can limit the size of the cache and the worst case is that some clicks go unlogged. To be explicitly clear, the ad server cache of CIs would only include at any given moment the most recent Banner impressions. The invocation code in each email would be different, but no more difficult to create than the CB parameter. And as a mail recipient, the email may include different banners each time I view it. What do you think?

Hi, @andrewatfornax @Erik Geurts. I'm new to the revive community, but am excited about what you're doing here. I like the idea of a multi-banner/campaign email zone that's capable of serving general ads. For me this is a value-add for general website advertisers. I'd like to bounce the idea for a simple solution off you guys. My PHP is weaksauce, but I'd be happy to hack out a proof of concept or possibly sponsor the development if the lift is minimal for the experts. Here's the idea - according to this knowledge base article, the lack of cookie and JS support in email clients makes it difficult to connect the banner impression (<img> tag) to the banner click (<a> tag). So this is just a state issue. If I understand the issue correctly, we can simply add a correlation identifier (CI) to link the impression to the click. The invocation snippet looks like this: <a href='http://ads.dev.local/www/delivery/ck.php?zoneid=1&amp;ci=INSERT_CI_HERE' target='_blank'><img src='http://ads.dev.local/www/delivery/avw.php?zoneid=1&amp;cb=INSERT_RANDOM_NUMBER_HERE&amp;ci=INSERT_SAME_CI_HERE' border='0' alt='' /></a> Each email message would have a distinct CI for it's banner, and use the same CI for each banner's <a> and <img> tags. The implementation seems simple: Maintain a server-side (in revive server) persistent cache that holds the most recent CI per impression Create a mechanism to trim the cache every N hours (to manage the size of the cache) Record clicks per cached CI; if the CI has expired, click goes untracked Please let me know if you think this is a simple and effective solution, and the best way to proceed? Keep up the great work!