Jump to content

Multiple banner in Mail Zone


thesios

Recommended Posts

I know that Revive Adserver has a limitation of a single banner per email zone 

I really don't know why, but it is there. So I have to ask is this limitation still valid?

I know the issue deals with the lack of cookies by the mail client, but there has to be a way to uniquely identify the client session, in order to determine which ad was served.

There is a third party plugin that claims they are able to serve multiple banners in an email zone.

So who would be interested in this feature?

Link to comment
Share on other sites

Hi @thesios,

Technically, you can only have one active banner in an email zone at a time. So, you can link multiple banners to the email zone, so long as the campaign start/end dates mean that only one banner will be active at any one time.

The reason, as far as I can recall from about 10 years ago, is that this was how the primary users of the application wanted it to work! Primarily, they were looking to send out assets as part of an email campaign, where the assets were specifically related to the email being sent out, so it was important to only have the one (correct) banner included in the email campaign. 

It was not intended for sending out "general" advertising banners in an email.

So, I don't think it has anything to do with "identifying the client session".

In theory, we could easily drop the requirement for only one active banner in an email zone at a time. However, that does, of course, mean that, if you're using multiple email zones, and you are trying to do branded assets, rather than general advertising, then you could more easily mess up and accidently have non-matching banners for your email campaign.

Perhaps two different email zone types would be better? One for branded campaign emails, and one for general advertising emails?

Link to comment
Share on other sites

Hi Andrew

Are you sure it is not a cookie problem as well ?  I didnt think the email clients ( outllook, tbird etc ) werent able to process cookies and without the cookie, there was not way to tell which banner was served.

 

It would be an easy test , could u point me in the general direction to remove the limitation?

 

Link to comment
Share on other sites

On 3/29/2017 at 11:18 PM, thesios said:

Are you sure it is not a cookie problem as well ?  I didnt think the email clients ( outllook, tbird etc ) werent able to process cookies and without the cookie, there was not way to tell which banner was served.

2

No, I don't think it was a cookie issue - when the banner request comes in, then Revive Adserver knows what banner it delivers, so it can log the impression. Similarly, when the click from the banner comes to Revive Adserver for re-direction to the destination URL, then it can log the click.

Certainly, it can't set a cookie for things like conversion tracking, and it can't do various limitations that depend on cookies, but I don't think that has anything to do with why the product limits only one active campaign at a time to the email zone. 

Link to comment
Share on other sites

  • 5 months later...

Creating single day campaigns is just too much work, in our case it's not worth it because the email banner is just some "extra" that we would give to those who have booked a regular website banner campaign. Now it can be only one. Using a plugin for changing the email banner sounds nice though.

 

Link to comment
Share on other sites

That's a bit like hacking Revive. :) But I'd rather do this with in-house means, or with a good valid plugin or not at all. After all, it's production, not experimental.

I found two plugins to use multiple banners in an email zone. The price is $60 each.

1. http://www.openxmods.com/openxmods/Multiple-ads-in-an-email-zone/prod_1461.html
They don't explain how their plugin works. The 2-server and source code options are slightly cheaper here.

2. http://www.reviveadservermod.com/others/multiple-ads-in-an-email-zone
You can see an example of the bannercode here and a short explanation. If I understand correctly, the email recipients will see a new randomly picked banner each time they open the email.

That's nice, but still I think just changing the banner daily would be easier. The email banner code would be the same, and if campaings usually run several months (which is the case at our site), then a daily rotation of all two or more banners in the zone would be quite fair to the advertisers too.

Anyway: Anyone got some experience with one of the plugins? Unfortunately there is no try-before-you-buy option.

 

Link to comment
Share on other sites

  • 4 months later...

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:

  1. Maintain a server-side (in revive server) persistent cache that holds the most recent CI per impression
  2. Create a mechanism to trim the cache every N hours (to manage the size of the cache)
  3. 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!

 

Link to comment
Share on other sites

Hi @Chad,

I see where you are coming from. However, think about this - the invocation tag, which you're going to put into the email that you send out, is generated once, when you go into zone in the Revive Adserver UI, and generate it.

This tag then needs to be put into the email that you send out, and, when you send it out, it calls back to Revive Adserver, and retrieves the appropriate banner to display. 

However, what you are proposing is that every email that gets sent out has a *unique* invocation tag, with a server-side maintained list of unique correlation IDs - one for every email that is sent - so that *every* email that you have sent has a unique ID, allowing for potentially delivering a different banner to each email recipient, while still being able to track the clicks correctly.

So, my question is - how does this happen? How do you generate a unique ID for every email that gets sent? Presumably, this would require some form of integration between your email sending utility and (perhaps) an API in Revive Adserver. (That, or adding functionality to Revive Adserver to also allow it to do bulk emailing, but I definitely do not want to do that.)

 

However, if the goal is just to be able to send out an email campaign, but with with a number of different banners appearing across the spread of emails sent, would it instead be possible to do this by randomly inserting a number of different email zone tags through the email campaign, or perhaps using direct selection?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Hi @Chad,

As always with Revive Adserver, unfortunately, we do need to consider how the solution would work "at scale". While you might not intend to use any solution for more than a few emails, and don't expect clicks to happen after a few hours pass, the fact is if we implemented it, then we'd have users who send out thousands (millions?) of emails, and they would expect the banners to be able to clicked any time. So, we'd have to make sure things work forever, so I do worry about performance.

Back to my original point though - if you're using PHP to generate random CB argument values already, how many different banners do you want to put into an email campaign? Could you not just set up multiple campaigns, and randomly insert different zone tags into the emails as you send them out?

I appreciate that doesn't mean you get a different banner appearing in the email each time you view it, but we can't offer that solution anyway. All a unique CI value (per email sent) would do would be to allow Revive Adserver to uniquely identify (anonymously) the a user the email was sent to, both when requesting a banner to view, and when the click comes in. But because the CI for the click URL has to be embedded in the email, just like the CI in the image URL for the banner itself, although Revive Adserver could randomly select a banner to show the user, and record that user/banner combination in a cache, it could not after that select a different banner to show, because otherwise, when a click comes in, was the user clicking on the first banner we sent to them (they kept the email open), or the second one we sent (they opened the email on another device), or the third email... ?

We could only ever send one banner, and the user would have to see the same one again and again - just like sending a randomly selected zone in the first place!

Link to comment
Share on other sites

@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:

  1. alternative approaches (perhaps a custom plugin)
  2. managing duplication of logic in the zone-per-advertiser approach
  3. 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)
  4. 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!

Link to comment
Share on other sites

Hello,

Thank you @Chad and @andrewatfornax for discussing this. On the topic of generating a CI for each email, could you use the recipient's email address? Many ESPs will provide merge codes for that so that even if you're using the same email template to send to 500 people, the emails can have a different CI for each recipient. For example, SendGrid has a [%email%] merge code and MailChimp has a  *|UNIQID|* merge code. The former is the plain email address while the latter is, I believe, a hashed version of the email address. That would at least eliminate the need for a Revive user to generate GUIDs per email.

Thank you!

Link to comment
Share on other sites

Hi there.

I joined this discussion earlier, before you guys started to get really into technical details. Which is great. :) Unfortunately I can not contribute very much, but might I suggest something:

I really think, especially considering the problems with more complex or unique banner codes etc., two simple and elegant solutions while using the same simple banner code for email banners as now: Make revive swap the banner & link which are returned for this email zone.

Maybe a) on a timely basis, trying to make it equally shared for all campaigns in that zone according to their probability or b) swap on each delivery, or each 10th/100th delivery again equally shared for all campaigns.

What do you think?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...