Mike Pearce – blog

Arbitrary or remote conversions with Google Adwords

Posted in PPC by Mike Pearce on March 23, 2010

I’ve been investigating whether or not you can fire conversion into Googles AdWords platform remotely. I’d like to send in a conversion event when I get a conversion from a keyword via a source that isn’t a webpage. Google supplies you with a chunk of javascript which you can drop onto any page on your site (or attach, via javascript, to an event, such as an onClick or whatnot) and, when fired, sends a conversion into AdWords.

This is assuming the user has clicked on a PPC keyword first and converted in the same session, if they haven’t you’re shit out of luck.

In my context, a user will land on a page and call a number. I can trace the fact the number has been called and I want to fire a conversion into AdWords, except I can’t, because I’m not that user. I have tried dropping the javascript onto a hidden page on the site and remotely calling that, I’ve even tried just calling the image src of the <noscript> image. I’ve done this via a browser and also via curl. None of it works.

Because I don’t have the users’ cookie.

This, in my opinion, is a massive oversight on Googles part. I’m spending (well, I’m not, but a user with an AdWords account might) a lot of money to have my keywords shown and, unless my service is something you can purchase or convert online, I have no way of tracking the efficiency of those keywords. Fail Google, fail.

Google never explicitly says that I can’t do this, but they don’t explicitly say I can either. Searching for the answer on Google (or Bing, in case Google are cheekily hiding the info) turns up nada, except people bemoaning the fact that they also cannot do it.

One of the things I have found people talking about is PayPals IPN (Instant Payment Notification), basically, when a user purchases something via PayPal, when the money is actually debited from the users account, PayPal sends an event to an IPN URL, which is a page on your site, which, after confirming the call is from PayPal, can use a bunch of data to store the fact your user has paid on your own site. This is useful because often, people won’t click back to your site from PayPal once they’ve made the purchase, so, if you do something fancy on the confirmation page, you might lost up to 30% of your confirmation page visitors.

This is the page that Google want you to put your conversion code on. A page that may lost up to 30% of it’s traffic from leakage at PayPal.

Sucks right? Nothing you can do about it.

C’mon Google, give us an API or something we can poke conversions into AdWords with!

Resourcing, it's just an estimate OK?

Posted in Estimating/Planning by Mike Pearce on March 5, 2010

Reign of the Supermen by fengschwing

Reign of the Supermen by fengschwing

It is NOT an indicator of how much work the team is doing, right?

Too often, businesses seem to think that the resourcing we do during sprint planning to work out how many ideal hours we have, allowing us to decide what we can fit into a sprint, is an accurate reflection of how much work the team can/will do.

It’s not, OK, chill out. At BEST it’s a worse case scenario.

The average work day is 7.5 hours. That does not mean that I can dedicate 7.5 hours of work to tasks from the board. When we used to do resourcing, the business would estimate our resourcing for us:

There are seven people on the team doing a two week sprint, therefore, you have 490 man hours in this sprint, fit stories and tasks in that equate to those hours, you can have 15% of that figure for bugs.
-Somebody from the business

We quickly realised (well, as a team, we realised this was wrong immediately, but the business will always wait for empirical evidence first) that this wasn’t going to work. There is no way each team member can dedicate seven hours a day to the sprint. There are numerous things that vie for your time; getting a coffee, taking a piss, talking to colleagues, talking to the business, researching your industry, emailing your wife, checking your bank balance, rebooting your Windoze computer on a AD network which takes about 15 minutes, getting a coffee, etc, etc.

So, sprint after sprint failed (let me be clear, the sprints didn’t “fail” as the business always decided we “drop” something low priority from a sprint before the end but, as a team, that feels like a failure) and this could be down to bad estimating of ideal hours for tasks, true, but this is compounded by bad resourcing.

If you resource incorrectly, your entire sprint is undermined as it’s the basis for deciding what you commit to, you have an inflated idea of how many ideal hours you can deliver and so you over commit. Your gut feeling is always “this is too much work, we’re overcommitting!” but the math is right? So, it should fit in, right? RIGHT?

No, wrong. It won’t. Neither will pretending it will fit in and then dropping stories at a later stage work either. This will undermine the teams ability to deliver quality working software as there is always this grey cloud of unachievable stories hanging on like a bad smell at the end of your sprint backlog. The team will inevitably rush through what they’re doing to try and deliver what they’ve (been forced to) commit to. This is bad on many quite obvious levels, so I won’t spell them all out…

… OK, I will. This will result in less than polished code, rushed, hurried unit tests. Bothered and harrassed QA roles (if you have them) a stressed release manager as he’ll be backward and forward with UAT, an annoyed stakeholder as the stories get rushed, other annoyed stakeholders as their stories get dropped and, finally, a shoddy release of badly written, implemented, tested and released code.

Exaggeration? Maybe. But it makes my point.

If you ask each team member “How many hours a day can you commit to, ideally?” when you’re resourcing. You’ll get a worst case scenario on the amount of ideal hours you have. If you then estimate and plan based on that, you’ll ALWAYS deliver what you commit to (unless you get the planning REALLY wrong) and, usually, have time at the end to pick up an extra story, fix an extra bug, research a new technology or whatever. Everyone wins; the team are happy that they’ve delivered what they’ve said they would (and, maybe more) and the business is happy as they’ve managed external expectations and delivered the commitments and perhaps even more happy if another story was squeezed in, or an extra bug or two squashed.

I understand that you need to know where inefficiencies are, I really do, I want to know also. If the team are kicking around spending three hours a day reading XKCD and reading LOLCats, then I want to know as well and why. But they aren’t they’re spending the time doing actual work. So, let them do it and don’t force them into it.

If you want to measure time spent on things other than the sprint, then use something other than the sprint to measure that time. Resourcing and estimating/planning won’t help you here as they are, after all, just estimates.

Follow

Get every new post delivered to your Inbox.

Join 912 other followers