MutateJobService.mutate unit cost

[George Ciubotaru]

Hello guys,

I'm trying to better understand the pricing model of the API. I'm mainly using MutateJobService with relatively big number of operations per job. From the Rate Sheet (http://code.google.com/apis/adwords/docs/ratesheet.html) I understand that the price for 1 MutateJobService.mutate job is 1 unit per  SimpleMutateJob (I'll have just 1 SimpleMutateJob no matter how many operations within the job). This is too good to be true... am I missing something here?

Thank you,

George

[Anash P. Oommen]

Hi George,

That's the cost for creating the job. The actual cost will be

cost for creating the simplemutate job + cost for simplemutatejob for completion + (actual cost for operations in synchronous mode)/2.

Cheers,

Anash P. Oommen,

AdWords API Advisor.

[George Ciubotaru]

Hi Anash,

Where can I find more details about this formula, I didn't find it documented anywhere? For example what is "cost for simplemutatejob for completion"?

Anyway, the most expensive part of this formula is (actual cost for operations in synchronous mode) / 2. I'll try to compute this figure for the following scenario:

- 500 new campaigns

- 5,000 ad-groups in each campaign (total 500 * 5,000 = 2,500,000 ad-groups)

- 1 ad per ad-group (total 2,500,000 ads)

- 1 keyword per ad-group (total 2,500,000 keywords)

From the Rate Sheet the price per unit:

- 1 unit per campaign ADD operation

- 1 unit per ad-group  ADD operation

- 40 units per ad  ADD operation

- 15 units per keyword  ADD operation

The total units is: 500 * 1 + 2,500,000 * 1 + 2,500,000 * 40 + 2,500,000 * 15 = 140,000,500 units

The figure to be used in the above formula would be half => 70,000,250

The price per 1000 units is 0.25$ => total price: 17,500$

I got to be wrong somewhere, it is too expensive. Can you please confirm (or hopefully deny) the above?

Thank you,

George

[Anash P. Oommen]

Hi George,

Let me clarify - when you create a SMJ, you start by creating the job (MutateJobService.mutate.ADD, 1 unit per job). Then you poll the service at regular intervals to see if the job completed (MutateJobService.get, 1 unit per job). Once the job completes, you retrieve the result (MutateJobService.getResult, 1 per JobResult). 

So to run a job, what you need is 1 * mutate + N * get + 1 * getResult, where N is the number of times you poll the server to see if the job completed. In terms of cost, that would be 1 + N * 1 + 1. Add to that the actual cost of operations / 2 and you get the total cost. The clause about 50% cost reduction for MJS is listed on the rate sheet at http://code.google.com/apis/adwords/docs/ratesheet.html. It lists the cost reduction for BulkMutateJobService, but MJS also gives the same cost savings.

Also, yes, your calculations are correct. However, we provide free units to developers under some cases. See http://support.google.com/adwords/bin/answer.py?hl=en&answer=45891 and http://www.google.com/adwords/api/preferredpricing/ if you are interested.

An additional thing about the scenario you mentioned - I assume it is hypothetical and you mentioned it for discussion purposes only. If it isn't, then 1 ad + 1 keyword per adgroup isn't going to work very well unless you expect the users to search for that very specific term (e.g. a camera model name). What might be more effective is one ad and a few (6-7) keywords. You might also want to explore Ad Params (http://adwordsapi.blogspot.in/2009/11/more-dynamic-ads-with-ad-parameters.html) and dynamic keyword insertion (http://support.google.com/adwords/bin/answer.py?hl=en&answer=74992) to see if that helps in cutting the number of ads

Hope this helps. Let me know if you have more questions.

[George Ciubotaru]

Hi Anash,

Thank you for the detailed answer.

I think you should update the Rate Sheet page with these details, now it is not at all obvious how the price is calculated.

We are indeed using 1 ad + 1 keyword per ad-group because, as you've noticed, we do target specific terms. This is the reason we have so many ad-groups per campaign.

Thanks,

George