But what has this to do with Advertising Operations? Well, I feel the similarities occur when thinking about building scalable & highly redundant/available systems (as they say themselves, they value availability over consistency). There’s quite a deep dive into their decision about using Cassandra which I found insightful and educational and well worth trying to get to grips with as it’s becoming increasingly clear that the whole NoSQL field (certainly in so far as the amount of data we are able to generate within online-advertising systems) has many benefits over traditional DB systems.

Data Management Part I: What Are Data Management Platforms?
Data Management Part II: Centralize and Synchronize Your User Data
Data Management Part III: Syncing Online Data to a Data Management Platform
Data Management Part IV: Syncing Offline Data To Your DMP

I’d thoroughly recommend reading these as they are a great introduction to the whole data/DMP field from a specifically AdOps perspective. Irrespective of whether you currently have any plans or strategies around leveraging the data your various adserving, analytics & behavioural platforms provide, these articles will give a solid view of what and how these technologies can start to work together.

If you’ve not seen this already Joelle Frijters over at Improve Digital has recently posted up an article which takes that Luma landscape concept and reworks it.

Personally I prefer the Improve Digital version. Not only does it simplify the layout but it logically groups them into their core areas of specialism (and in doing so I feel clarifies the current field or providers & operators) but there’s also a helpful glossary of the every-changing acronyms we like to use.

Article: http://www.improvedigital.com/improve-digitals-display-advertising-eco-system-map-201112-gets-great-reviews
PDF: here

Netmining Panel: Mapping the Display Landscape (West Coast Edition) from Netmining on Vimeo. Industry experts discuss how to successfully navigate the constantly evolving display ecosystem and identify valuable best practices for marketers. The panel features Alex Hooshmand of BlueKai, Qasim Saifee of OpenX, Raj Gajwani of TARGUSinfo, Anna Partel of Right Media – Yahoo! and Jeremy Woodlee of Google. Moderated by Maureen Little of Turn.

Download Netmining’s Guide to the Display Landscape here:
http://www.netmining.com/displayguide/

http://placekitten.com/300/250	http://placekitten.com/300/600

Link: http://placekitten.com

Some additional features I’d like to see are:

• Search based filtering. Many sites will fire off a couple of hundred urls in a single page load, drilling down through the mess to those specific urls you’re looking for would be easier with some sort of filtering. httpWatch has probably the best filtering I’ve seen on any similar tool to date, I couldn’t see any search functions at all
• On the timeline I’d like to see the a clearer indication of the various aspects of each connection eg; have the DNS lookup in one colour, connection in another, first-byte download in another etc. Whilst this is available if you go into each call/line-item it would be nice to have the option to customise this output.
• It would be great to have the ability to export the data in different formats eg; CSV.
• Display Flash objects in the preview tab. Currently it renders GIF, JPG PNG etc, it would be nice to have the Flash object rendered as well.
• Display any video data eg; dimensions, codec, audio/video bitrates etc.
• Non HTTP traffic such as streaming services, eg; RTMP, RTMPT, RTMPE, RTSP & MMS

It’s certainly a step in the right direction and I’m most grateful for this latest addition to Chrome. My continued favourite tool is httpWatch, not only does it provide excellent filtering/search capabilites but genrally makes tracing HTTP calls a little easier than the curent Google Developer Toolbar does. However, a team licence (that’s four licences) for httpWatch will set you back just under £1000.

Further Information:
http://code.google.com/chrome/devtools/docs/network.html

Cloud Four has an article on iPad orientation detection through CSS here:
http://www.cloudfour.com/ipad-orientation-css/
They supply an example of their techniques as well:
http://www.cloudfour.com/ipad-css/

NCZOnline – iPad web development tips:
Amongst other topics covered this article deals with the all important: User-agent string, iPad detection through Javascript as well as ways to ascertain screen dimensions and orientation:
http://www.nczonline.net/blog/2010/04/06/ipad-web-development-tips/

Smashing Magazine has porovided some well thought out issues to consider when starting out developing web-pages for the iPad & iPhone:
http://www.smashingmagazine.com/2010/05/28/web-development-for-the-iphone-and-ipad-getting-started/

HTMLGoodies has an article detailing more in-depth approaches to orientation on the iPad & iPhone:
Detect and Set the iPhone/iPad’s Viewport/Orientation Using JavaScript, CSS & MetaTags

Using CSS to handle Orientation on the iPad:
So, the upside is that this is a lot easier than you might think. WebKit/Safari supports the CSS media query declarations based on orientation. You can simply specify two CSS files which contain the layouts for portrait and landscape and place the following two lines in your pages HEAD tag.

<link rel="stylesheet" media="all and (orientation:portrait)" href="portrait.css">
<link rel="stylesheet" media="all and (orientation:landscape)" href="landscape.css">

And then simply amend the layout for each orientation accordingly, in the example below they use it to hide/show a H1 tag accordingly. Here’s a working example:
http://www.cloudfour.com/ipad-css/.

It occurs to me that the timing is very apt. As we head towards the end of the first month of 2011, sales teams will be frantically ensuring they are hitting their targets. It is an unfortunate situation but in such times due-diligence can be easily sidelined in the frantic dash to secure revenue for those last closing days of the month. So, if you’re seeing any new accounts suddenly appearing trying to force their way past your normally thorough screening process… be careful.

On the desktop I have access to numerous tools that help me understand and debug what my adserver is doing. Tools such as httpWatch, httpFox, Fiddler2, Charles, HTTPScoop and FireBug. These tools intercept HTTP traffic and allow you to analyse, check and view the response from the remote adserver. I use this extensively to test response times, debug connectivity & delivery issues, view mimetypes & cookie data amongst other tasks. Once you’ve used these tools it’s difficult to understand how you’ve managed so long without them… that is until you start delivering ads outside of your desktop environment where these tools no longer exists or the devices are unable to provide this information natively or without jailbreaking/rooting your phone.

So, when we started developing the next iteration of our iPhone app we needed to create an environment where we could replicate the tools we’ve come to expect on the desktop for the mobile app as well. Having just moved our entire team to MacOS from Windows based machines this proved to be interesting.

How this works:
Basically we are creating an ad-hoc network on your Mac desktop which the iPhone or other device can connect to. We are then going to route the mobile traffic through your desktop’s Ethernet connection. HTTPScoop sits on the ethernet connection watching and reporting all traffic that flows through it to port 80 (or whatever port you have decided to monitor). This method allows you to visualise the HTTP traffic of your iPhone/Android etc on your desktop and enable you to check these calls are being made correctly. This tutorial describes how to setup your desktop (I’ve used Snow Leopard, MacOS X here) to intercept and display HTTP requests using HTTPScoop made by your mobile device. it requires that you have or are running the following:

Requirements:

• MacOS X (I’m using 10.6 – Snow Leopard) running Airport
• A working copy of HTTPScoop (http://www.tuffcode.com/) Free 14 day trial or only £10 per licence
• An active internet connection.
• Mobile device running the app you need to test

Process Outline: This is what we’ll be covering.

1. Using Internet Sharing create an ad-hoc wireless network through your Airport card.
2. Connect mobile device to the ad-hoc wireless network
3. Start HTTPScoop and configure to show http ethernet traffic
4. Activate the mobile app and watch the results.

Create an ad-hoc wireless network through your Airport card.

1. Got to System Preferences and click Sharing under the ‘Internet & Wirleess‘ group.
2. If needed click the padlock to make changes
3. In the Services list click Web Sharing, we need to activate this as otherwise internet sharing will not work properly for some reason.
4. Next click the Internet Sharing service, options (‘Share your connections from’ and ‘To computers using’) will appear to the right of this.
5. Choose Ethernet from ‘Share your connection from:‘
• tick Airport from the list ‘To computers using‘
• click ‘AirPort Options‘
• Name your Network eg; ‘AdOps’
• Enable WEP encryption and add suitable password if needed (it is WEP after all!) & click OK
• Tick the Internet Sharing box (in the Services list) to activate it, this will grey out the Internet Sharing options., the icon should now have turned green (previously it may have been red). You will be asked for your password to authrorise this.
6. Tick the Internet Sharing Box this will activate Internet Sharing, you will be asked to confirm this is what you want, click ‘Start‘ to continue.
7. Retick the padlock to submit and lock the changes.
8. Your ad-hoc wireless is now setup and ready for you to connect your mobile device to it.

Start HTTPScoop and configure to show http traffic: Connecting to and tracing/view those HTTP calls.

1. Start your copy of HTTPScoop. Next we will configure it to show the traffic you want.
2. Choose the Ethernet (‘eth0‘ or ‘en0‘) option from the dropdown to the right of the HTTPScoop window) then click ‘Scoop‘ – this will start to track all HTTP traffic on your ethernet connection NB: You may see other traffic appear if you have other apps/browser running in the background which are active. To make things simpler close any browsers and other apps using HTTP Traffic down (eg; RSS readers).
3. Click the ‘Scoop’ button, this will start recording the HTTP traffic, as this is a privileged service you will need to enter your password.

Connect mobile device to the ad-hoc wireless network:

1. Connect your iPhone/Android/Tablet or other device to the newly created ad-hoc network.
2. Start the application you wish to monitor, after a while & when the app is making HTTP calls you will start to see data being recorded into HTTPscoop.

Caveats & Postscript:

• HTTPScoop by default only monitors HTTP traffic on port 80. If you need to monitor other traffic eg; HTTPS on port 443 then this can be accomplished by turning HTTPScoop off and amending the ports monitored through HTTPScoop->Preferences.
• Yes, I am aware that this method does theoretically allow you to set up and adhoc network and monitor any attached device (whether it belongs to you or you have permission to view this data or not) so please use this method wisely. Be aware that you MUST have permission to intercept the mobile device’s HTTP Traffic, capturing unauthorised HTTP traffic may be illegal in some jurisdictions..
• HTTPScoop has more help/information here: http://www.tuffcode.com/support.html
• I’ll be posting alternative methods using different software (eg; Charles debugging Proxy) as well as methods that work on Windows very soon.

Links:
HTTPScoop

As much as we have to keep our eyes on the ball regarding the challenges of HTML5 and the plethroa of data aggregation/targeting tools entering the market the Semantic Web promises some interesting and exciting opportunities for AdOperations in the coming years.

What you need to know about Semantic Ad Targeting.

And here’s some interviews with Amiad.