Ad Targeting use case for Aerospike


#1

We have seen the db being popular with the ad industry. Would like to know and take guidance from people on preffered/prevalent ways of maintaining ad targeting information in the database for a ad server to efficiently query it without compromising much on latency.

One way of storing it I can think of is to store the keys for each targeting criteria and query the database for that key. But still confused if I can utilize lua or any other technique to reduce the work on client side and minimize latency.

Are there any examples on how we can store the data in Aerospike. Urgent help is required. Thanks in advance :smile:


#2

Just tweeted out about this, to see if we can broaden input:

@PeterCorless: @aerospikedb forum Q: Ad Targeting Use Case - dev looking for input. #AdTech #RTB #NoSQL #LUA - See: http://goo.gl/59JHnE

Have you considered also x-posting to other groups? On LinkedIn, there’s a closed group:

"Ad Exchange Masters - DSP DMP SSP RTB Retargeting Programmatic TV Trading Desk Geofencing Ad Tech" https://www.linkedin.com/groups/Ad-Exchange-Masters-DSP-DMP-1887819/

That’s probably better than a generic “NoSQL” group.

Hope you get some good input!

Peter Corless Aerospike pcorless@aerospike.com


#3

Thank you so much Peter. Means a lot :smile:

Hoping to get good suggestions soon as time is critical. Fingers crossed.

Did not understand the x-posting to closed group. Please elaborate. Sorry for the confusion.

Regards, Dragon


#4

x-post (cross-post); as in, to put your request in multiple groups or forums.

In the meanwhile, if it is urgent, if you want to email me your contact info, I can try to get you callback from someone here to discuss your issue.


#5

It’s hard to answer this without more information as it really depends on lots of factors. Do you have more information about your platform, targeting params, what kind of ads, latency requirements, etc?


#6

Hi Mani,

Targeting criteria that can be on various params ranging from age, geo, daytime, etc, the ads will be streamed through CDN and latency requirements are very strict as with any ad server i.e. in ms.

My intent to ask the question to get an industry view and probably guidance from Aerospike community as I have been reading that one of the biggest beneficiary of Aerospike has been ad industry. Therefore, would be really helpful if I can receive some inputs on how do people store the information, best practices, high level data design and approach.

Hope I am able to add more info.

Thanks & Regards.


#7

Hey Dragon,

We are part of the mentioned Linkedin group, but I saw this in my email. From our research of other ad companies, and internal use, it looks like Aerospike is primarily used as a high performance caching layer. At SmartRTB, we primarily use it to store ‘limbo’ impressions that have a very short lifetime but require quick access during the RTB process.

UDFs are also a great feature depending on your requirements.


#8

Thanks Evan for the reply.

I saw the use case video for SmartRTB on youtube. I am planning to store the keys for targeting criteria in Aerospike for e.g. if some ads are targeted at country level, then against ‘US’ as my key, I am planning to store the eligible ads in Aerospike. At runtime we can get the ads against ‘US’ key if request comes from US, will that be a good idea or should I keep this in local cache. Any tips on better ways to store the targeting info .

Moreover, I wanted to ask you about the use of StreamUDF as while exploring UDF, found it constrained at key level or multiple records against a secondary index. Won’t that be slower than primary key? Moreover, will it be faster to perform some mathematical operations in java or using lua.

Awaiting your reply.

Thanks.


#9

Hi Dragon, wondering if you could share how you ended configuring things for your use case?


#10

Hi Guru,

We thought it would be easier to have the keyset based on the targeting category and value combination. you can update the metrics based on the keyset. For us the targeting categorical values were limited in number and we could easily update the numbers without outnumbering the keyset space or need for multiple namespaces.

Regards, Dragon