AdSense Dashboard 2.7

/

So as a part of the V1 launch of the API, there are a few things that are happening.

First and foremost, we don’t need to hide the fact that the API exists anymore; this means we can move to OAuth2 for our authentication. This miiiiiiight be a little flaky; I’ll be watching for problems with authentication, and if you have problems, tell me. Also, we’ll be moving to an explicitly read-only auth scope, and a human-readable scope at that, so that users can feel confident that we can’t do anything untoward with their data.

Next, this is the first pass on a multi-pass redesign of the look and feel. Specifically, we’re going to be surfacing a lot more data - so we need ways of making all that data work. As such, we’re moving to ViewPager, the same pager UI you see in Market and Google+.

Gotchas:

  • Auth might be a little flaky. Working on it.
  • Graph rendering is really slow, especially now that there are six of them on screen.
  • There are a lot of UI tweaks needed, here; the app isn’t the prettiest thing in the world.

I’ll continue to work on this over the next few weeks, but again, I’d like to thank everyone for helping us test the AdSense Management API - we wouldn’t have been able to launch it with the level of confidence we have today without each of you.

Thank You, Beta Testers!

/

So the secret can now be told - AdSense Dashboard has been a skunkworks project to test Google’s prototype AdSense API.

Together, we generated enough traffic to verify the production-readiness of the API; thanks for enduring the occasional downtime as we got the API ready for the masses and for its public release, and thanks to the AdSense API team for doing such amazing work under difficult time schedules and a rather large amount of pressure from me on the shape and form of the API.

This isn’t the end of AdSense Dashboard - in fact, it’s just the beginning. But for now, the limelight belongs to our API launch.

Read the complete Adsense API Announcement

If you’d like more information on the API, you’ll find the public documentation is now available. Now that we’re public, I’ll be changing the auth method from ClientLogin (which reported “AdSense” as the permissions it wanted when you attached an account) to the OAuth endpoint for the API, at which point it will tell you that it wants read-only access to the API, further limiting the set of permissible actions that can be taken by the code.

Thanks again to everyone who’s installed the product and helped us test our API.

AdSense Dashboard 2.6

/

I’ve been pumping out dashboard changes for the last few days, based on feedback, bug reports, and general email discussions with users. Keep them coming - if you use the app, I want to hear from you.

Users on Eclair/Froyo got bit by a pretty nasty bug in the HTTP stack built into the phone; the common fix appears to be to not use that API on those platforms, so that’s what I’m doing.

New stuff:

  • Support for disabling auto-refresh.
  • Bugfixes for Eclair/Froyo. If it’s not fixed for you, I want to hear about it.
  • Device-specific compatibility bugfixes around currency and rounding.
  • Google TV support. This is a bit slapdash - I’ll improve it as I improve the tablet layout.
  • New widget (released as part of the 2.5 chain) by a contributor/coworker.

There’s a lot of activity going on this weekend and early next week; I intend to do a lot of ‘remastering’ of the numeric portion of the display to show more comparative data - today versus yesterday, today verus one week ago, this week verus last week, this month versus last month, etc., for a broader set of metrics than we currently include.

That will also be extracted into widget form - choose an arbitrary 1x1 fact.

Lifetime spend, custom channels, and url channels will also show up, in all probability.

Your feedback isn’t just welcome - it’s wanted. Ping me with your gripes, comments, suggestions, and requests.

AdSense Dashboard Released

/

I’ve released a new (free) app to the market for AdSense publishers to track their performance. AdSense Dashboard is exactly what it sounds like - a heads-up dashboard for Android devices that shows vital statistics about your AdSense account.

Over time, I’ll be adding features designed to fulfill a specific need: the need to know, at any moment, what’s happening to your revenue and traffic. We’ll be adding new facts, improving the quality and usefulness of the default report, pushing the data table onto more layouts, extending downwards to support smaller devices, and adding widgets so that you can get the most important information on the home screen, to be reviewed hundreds of times a day.

Check out Adsense Dashboard the Android Market.

In Search Of Quality

/

Well, we’re getting back on track.  I’ve spent some time trying to return us to our previous levels of quality, and enable us to move forward on adding longer blacklists again.

I believe I’ve been able to return us to the previous state of affairs successfully, now - but the cost isn’t cheap.

The solution depends on the fact that we do have a known sort order for all returned results - interestingness.  If we assume that interestingness, as a score, is stable and not random, that should mean that our query can be split not only by positive term, but by negative terms, and taking the intersection of results for a particular positive query term; if a photo doesn’t appear in all of the split queries for a positive term, then it must contain one of the negative terms, and can be discarded from the result set.

This means, again, we’re doing a lot more queries. Specifically 6 locations * 2 years * # of positive search terms * (# of negative search terms / 9) ~= 1.5k Flickr API requests per search result as a worst case. (This used to be a lot higher - I’m having to bring down the search range in order to allow for more queries per positive term.)

Now, we do a lot of caching along the way whenever possible, because, again, this is a free service on freebie quota, but that’s a lot of outbound API calls per inbound user request.

Hopefully things look better again.

Well, that was fun. Not.

/

Cataclysm.

  • A raft of exceptions started turning up with geolocation and weather. Turns out Yahoo’s weather service isn’t as smart as I thought it was, and outside of major city centers it can be difficult to tell at exactly which level weather is mapped in at, if anywhere. We now do weather feed pulls at levels 13, 11, 9, 6, and 3 in the hopes of finding something useful. If you live somewhere other than a major city, chances are your weather just got more reliable.
  • If we can’t find weather, we’ll return weather conditions for unknown. I think that means more people will see volcanoes. I think I’m okay with that.
  • We were previously directly calling the memcache API, which sounds nice on the surface until you realize that actually it’s quite unreliable as a cache (within the wider definition of ‘reliable’) and that you really ought to wrap it in a bit of cache management. I’ve done so, so that when problematic keys come up, they get discarded, and we silently ignore fails to update caches (as it’s not fatal, or at least, ought not to be.)
  • We’re doing so many more searches that the search results’s size basically exceed the storage limits on a memcache key. I’ve split that out into caching search results for each search, instead of the aggregate search set, to get better fan-out; it also means we’re doing an aggregate query for cached results across multiple keys simultaneously, which, due to magical google infrastructure, should improve performance for search caching.

Anyways, that’s what I get for getting too eager; I could easily have canaried it and paid a more watchful eye, but didn’t, and pushed it along with the new client binary all at once. While most people might only have seen a sluggishness in updates, I saw…. I think it peaked at about 10QPS of errors by midnight, due to a sea of broken shit that I didn’t test properly before I stuck it in production.

We’re back down to our more normal 1QPS of traffic, and our normal error rate (mostly due to Flickr taking too long to perform even these simpler searches - we’ve still got an upper bound on request fetch time of 10s), that client retries magic away.

More improvements, probably, soon.

Weathrman 4.0: By Popular Demand

/

I’ve got a shiny new Xoom, and now you have a shiny new Weathrman client.

The biggest changes here are all around two user stories I’ve heard more than anything else:

  • I installed the app, but it doesn’t do anything and I can’t find it.
  • I need more control over how the application uses data on my device.

To address the former, we’ve got a launcher, dialogs on preview, and an embedded usage guide to help the user get the live wallpaper selected on their devices.

To address the latter, we’ve now got a pretty good story on data controls:

  • We now obey background data settings. If you turn off background data support, you can still refresh the wallpaper manually, but all automated, non-interactive network activity is stopped.
  • Support for disabling use of 2G/3G and WiMAX networks, for those who want wifi-only.
  • Control over walllpaper refresh rate.

Now that we’re allowed a lot fewer search terms, we’re doing a lot more fan-out of requests to flickr; a single user can now result in about 5,000 flickr requests, fired off in under 30 seconds. The pressure is on to find better search terms and filter terms, and so our next steps will be to take advantage of the prediction API and start using machine learning to make better decisions.