I have been responsible for the development of MoreVisibility’s software that relies on the search engine’s APIs to manage and report on paid placement campaigns. I have been working with the Google AdWords API since version one, back in 2006. The latest and greatest release was announced Oct 7, 2011 and is about the fifteenth version. Back in 2009, they stopped using the sequential release number nomenclature at V13 in favor of a year time stamp. The newest release, V201109, has been eagerly awaited by the development community.
Back in the spring of 2010, in conjunction with major version releases, Google began inviting developers to attend an API workshop hosted in one of their seven offices in major metropolitan cities, such as London, Singapore, Tokyo, San Francisco, New York. This year I attended the NYC workshop and was able to meet the hard working Google developer advocates and fellow developers that I have been corresponding with via their forum. It was great getting to put a face to these helpful developers and to thank them for their tireless efforts to keep the developer community productive, via guiding us through their various versions of the APIs based on the AdWords platform. It was also a chance to get a better grasp on the new versions’ complexities, and take away best practices for security and efficiencies.
One of the most important functions exposed in the API is their reporting module. For agencies to effectively manage multiple clients’ budgeting, we need to get complete data efficiently at our finger tips. I believe that, in an effort to keep AdWords competitive Google will quickly deploy new advertising channels, without addressing the ease of measuring/reporting on these campaigns. As an example, many developers were unhappy with the V2009 series of releases, due to the fact that the new Remarketing channels’ data was very difficult to report on, due to it being buried in an Ad Performance Report and not in their Keyword Performance Report. Many in the development community reported the problem to the AdWords API forum and began requesting a super report that would properly provide metrics across all types of campaigns, such as traditional search, display, remarketing, mobile, location and whatever else Google deems worthy for effective internet advertising. As developers, we did not like to impose mandates to our team for the naming convention for certain types of AdWords campaigns, which would then allow our application programs to locate and manage the metrics.
The Google AdWords API developers processed our feedback and deemed it a high enough priority to address in their next release. The new “uber” report, Criteria Performance Report, which allows the downloading of all criteria types in one report was part of their latest release. To differentiate between the criteria, a new criteria type field has been exposed in the reporting, which allows for filtering upon pulling data and categorizing when pulling all data.
Also found in the latest release, is a new authentication option; the popular three legged OAuth, which is a commonly deployed open standard. While this may not be needed by all agencies, many at the conference had a need to obtain this method for account access to client’s not able to migrate to their My Client Center for one reason or another. Security is an important component for Google across all product platforms and a top concern of advertisers when entrusted with the management of their client’s hard earned advertising budget. So it is not surprising that Google expanded their options for authentication.
The workshop included a Mobile Best Practices track presented by, Sumit Chandel. Sumit had a wealth of statistics on the smart phone’s explosive growth and projections for the mobile internet users and their searching. It is expected that mobile users will surpass desktop users by 2013. This will require advertisers to have a fully functioning mobile presence. If you are still grasping with how to accomplish and could use some assistance in setting up your mobile site, please reach out and ask about our newest CMS for mobile product.
AdWords allows you to actively drive traffic via mobile targeted campaigns and ad extensions. AdWords does not leave out any bells and whistles for creating highly targeted mobile campaigns. One can select the carrier, language, platform, operating system, location, product and proximity that you would like for your ad to appear. AdWords will even allow one to leverage an extension for a click-to-call functionality. This will present an extra line of content in your ad for a clickable phone number. Being that this is a Google platform, they have tightly integrated with their Google Voice product to capture the call metrics, like number of calls and completed calls so you are able to measure your success.
One of the best takeaways from the conference is getting to know what Google is working on for future AdWords API releases. We can expect to see location targeting to the zip code level and shared objects for the efficient use across campaigns. As the mobile explosion continues to grow, they will continue to expand mobile device targeting options.
I received an email message that CommScore reported 14 million United States users scanned a QR code in the month of June. This begs the question, what are folks doing to leverage QR in their business? We continue to see the reports that smart phone shipments are outpacing PC shipments; it becomes when not if they overtake the number of PCs. All of these smart phones present opportunities for keeping your customers engaged, which means at a minimum one must have a mobile-friendly web site and content specifically developed for the growing number of smart phone users.
I think the US lags behind Asia and Europe in harnessing the marketing power of QR. I expect we will see more uses for QR, which will shortly morph into near field communication (NFC), by advertisers in ways that continue to improve quality of service and communication with their audience. For instance in Asia, one can scan a QR whilst commuting to work in the morning, and upon returning home that evening the product, will be at their door ready for use in the evenings dinner. Other examples I have found include embedding a QR/Chip into monuments for our departed to be remembered in a multi-media format. Headstone maker’s need only embed an inexpensive chip into the stone/vase/niche. If you have been to a museum in the past year, you have probably experienced this technology at work, when you scan and listen to the art history. Disney World’s Epcot even used this technology to allow children to engage in an episode of Kim-Possible, while mom and dad make their happy hour pub crawl through the world show case, brilliant.
It has been a very busy summer for IT departments that have integrated web services as part of their Application Program Interface (API) for business automation. Web services are designed to bridge the gap between business processes available over HTTP via standard browsers and the groups of companies that have developed business processes and APIs that are consumers of this information. For example, a search engine’s portal provides on-line reports concerning click data as well as maintenance panels for online marketing campaigns to humans via HTTP and a browser. In order to efficiently manage reports and track this data, APIs are developed to automate these human interactions with the search engines portal via leveraging their web services.
Due in part to rapid advancements in the technology supporting these channels, search engines are moving forward with so many new features such as re-marketing, mobile and video ads, that the pace of new web services is at an all time high. This means more work for the search engines to not only develop and deploy a human portal available over HTTP, but to also provide the interfaces for exchanging these new elements to their web services consumers; and attempt tokeep backward compatibility with previous releases.
Luckily, many years ago, IBM and MicroSoft teamed up to standardize how programs obtain their road map for using web services and created the Web Services Description Language, WSDL. It is an XML formatted document that describes the service being offered and its’ variables and method parameters. In theory, developers obtain the new updated WSDL and use one of the many tools that convert this XML document into source code in the form of Java, VB.Net, C#.Net, RPG or whatever language is being used by their IT department. The next step is to locate documentation and note deprecated processes and develop new logic to replace or possibly remove this logic from their API.
The challenges arise when the new web services no longer provide existing functionality, and are not backward compatible. It can be labor intensive to convert your logic to the latest version of the web services and then discover after hours of testing that it is not backward compatible. At this point, a developer has to begin lobbying the web service provider to reconsider this “fork” in their applications logic and to hopefully better understand what caused the vendor to change their logic. This process can either fall on deaf ears or be embraced and a patch released in a timely fashion. I am finding that vendors are human and may have overlooked a feature and attempt to patch quickly if resources are available and the number of complaints sufficient to warrant the work. Developers must present their detailed findings and provide ample documentation and supporting evidence to persuade the vendor to spend valuable time and resources to make the programming changes necessary to rectify. It helps if the communities of developers come to agreement when presenting their request for modification. Yes the blogs and forums are a key part to gaining a voice with the vendor and moving the modification through the process or to discuss ideas for a work around in the event the vendor is not receptive to the proposed modifications.