"Recently, some have claimed that we somehow stop advertisers from getting their AdWords campaign data out of Google."
I'm not sure who the "some" is, or what specific claims are at issue. Me? Certainly I've been writing about advertiser data portability (June 2008 and September 2009). But I've been writing about API-based data access, not CSV export.
I don't think there's any dispute that the AdWords Editor offers CSV export. I certainly never said anything the contrary.
But AdWords' comprehensive API offers a much more useful, flexible, and reliable method of export. For example, API-based export could let a tool developer write an app (either a client-based download or even a server-side script) that asks users for a Google password and a Yahoo password -- then copies all AdWords campaigns to Yahoo Search Marketing with a single click. Try that with a CSV! And consider advertisers who adjust their campaigns frequently. API-based synchronization would let those advertisers synchronize changes in their AdWords accounts onto other platforms. But CSV export would require a manual process at every turn. Do the manual process enough times and you're bound to slip up -- with serious implications for ROI, not to mention staffing costs and general overhead.
Crucially, the AdWords API already does everything that's required -- all the authentication, all the data formatting, etc. So what stands in the way? AdWords API Terms and Conditions, which specifically prohibit using the AdWords API to export data, even though the API itself is more than up to the task.
The DLF home page says DLF seeks "to make it easier for [users] to move data in and out." That's a laudable goal. DLF even says it should take "as little ... of [users' time] ... as possible" to move data. I think we all know APIs are easier, more powerful, and faster than manual (CSV) alternatives. So why do the AdWords API Terms & Conditions stand in the way?
My suggestion is simple: In the AdWords API T&C's, strike clause III.2.c. Let advertisers use the AdWords API however they see fit -- including moving data in and out, if they're so inclined. I look forward to DLF pushing the AdWords product team to make this important improvement.
I think what you are referring to only applies when you are creating a public application. Almost every SEM platform stores the data after pulling it out of the API.
I know in my previous SEM platform vendor, you couldn't edit Google campaigns from the SAME screen as YSM. Which is what III.2.c.i is talking about.
Basically you are talking about a "clone" funtion that takes in account the differences in match types and ad copy (multi-line vs. single line), replicates and uploads to the other engines.
I've seen this feature in other platforms, so I think you are reading the T&C incorrectly. I think it is a wording issue with HOW the data is actually stored, vs. being able to store it. What would be the purpose of the API if you could store the data and had to download it each time?
"Recently, some have claimed that we somehow stop advertisers from getting their AdWords campaign data out of Google."
ReplyDeleteI'm not sure who the "some" is, or what specific claims are at issue. Me? Certainly I've been writing about advertiser data portability (June 2008 and September 2009). But I've been writing about API-based data access, not CSV export.
I don't think there's any dispute that the AdWords Editor offers CSV export. I certainly never said anything the contrary.
But AdWords' comprehensive API offers a much more useful, flexible, and reliable method of export. For example, API-based export could let a tool developer write an app (either a client-based download or even a server-side script) that asks users for a Google password and a Yahoo password -- then copies all AdWords campaigns to Yahoo Search Marketing with a single click. Try that with a CSV! And consider advertisers who adjust their campaigns frequently. API-based synchronization would let those advertisers synchronize changes in their AdWords accounts onto other platforms. But CSV export would require a manual process at every turn. Do the manual process enough times and you're bound to slip up -- with serious implications for ROI, not to mention staffing costs and general overhead.
Crucially, the AdWords API already does everything that's required -- all the authentication, all the data formatting, etc. So what stands in the way? AdWords API Terms and Conditions, which specifically prohibit using the AdWords API to export data, even though the API itself is more than up to the task.
The DLF home page says DLF seeks "to make it easier for [users] to move data in and out." That's a laudable goal. DLF even says it should take "as little ... of [users' time] ... as possible" to move data. I think we all know APIs are easier, more powerful, and faster than manual (CSV) alternatives. So why do the AdWords API Terms & Conditions stand in the way?
My suggestion is simple: In the AdWords API T&C's, strike clause III.2.c. Let advertisers use the AdWords API however they see fit -- including moving data in and out, if they're so inclined. I look forward to DLF pushing the AdWords product team to make this important improvement.
I think what you are referring to only applies when you are creating a public application. Almost every SEM platform stores the data after pulling it out of the API.
ReplyDeleteI know in my previous SEM platform vendor, you couldn't edit Google campaigns from the SAME screen as YSM. Which is what III.2.c.i is talking about.
Basically you are talking about a "clone" funtion that takes in account the differences in match types and ad copy (multi-line vs. single line), replicates and uploads to the other engines.
I've seen this feature in other platforms, so I think you are reading the T&C incorrectly. I think it is a wording issue with HOW the data is actually stored, vs. being able to store it. What would be the purpose of the API if you could store the data and had to download it each time?
Could be wrong...