There’s more, of course - go see the AdSense Publisher Toolbar on the Chrome Web Store for more.

Specifically:

• A new, first-install page explains the product features a bit better;
• A First-install page added that explains product features in more detail, linked from help.
• An overlay notification is added when overlays are disabled on a domain, to help users find the feature.
• Choose your own reporting window on custom and url channel reports.
• Uses your current Google account login, rather than OAuth.
• Supports multiple logins.
• Fixes for timezone issues. If you still see problems, please report them.

Looking forward to hearing feedback.

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.

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.

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.

• Prettier 3D graphs
• Support for switching to 2D graphs
• Oooodles of end-user controls and settings
• The ability to disable chart series
• Checkboxes in the legend on the full-screen graph
• A widget for your home page that updates once an hour.
• Totals and averages on the data view.

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.

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.

• 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.

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.

This mean the load on the flickr API - and the load on my server - are going up.

I’m still in the awful position of not being able to charge for this, having made it free once - so I still want this to fall within freebie quota if at all humanly possible.

Last, I’ve got a shiny new Xoom, and I’ll be spending some time on the client shortly getting some basic changes into the UI to make it slightly prettier when used there.  I’ve already made some server-side tweaks to broaden the minimum image size so that Xoom resolutions get more Flickr results.  The biggest problem at the moment is that there just aren’t many large image sizes fetchable via the API, and the images that do come back are far below the 1920x1408 background image size that a xoom wants.

More soon.