Uploading Offline Conversions is Very Confusing, especially trying to do it Server Side only.

[Mark Jones]

Hello,

I am developing a server side application that needs to upload offline conversions.  I am trying to figure out if this is possible using

Service account where our production server can make calls to the Google APIs on behalf of my server side application instead of an end-user. 

After logging into the Google developers console and navigating to APIs & auth --> Credentials, clicking on the Create new Client ID button, we are presented with three options:

1. Web application - Accessed by web browsers over a network.

2. Service account - Calls Google APIs on behalf of your application instead of an end-user.

3. Installed application - Runs on a desktop computer or handheld device (like Android or iPhone).

Choosing Web application forces you to create a consent screen, but since I need to do all the work server-side without any user intervention the consent screen option does not seem to be the correct choice.  Seems like a Service account would be the best choice, but those accounts to not create a ClientID, ClientSecret, and RefreshToken.

All of the code examples point toward Web application where you are required to reference a Client ID, Client Secret, and RefreshToken.

Can anyone shed some like on this topic?  My goal is to upload offline conversions using Java and performing all the work server side.

https://developers.google.com/adwords/api/docs/guides/importing-conversions#code_examples

https://developers.google.com/adwords/api/docs/reference/v201409/OfflineConversionFeedService

https://developers.google.com/accounts/docs/OAuth2?hl=en_US#serviceaccount

https://developers.google.com/accounts/docs/OAuth2ServiceAccount

[Michael Cloonan (AdWords API Team)]

Hello,

You should use an Installed application rather than a Service account. This will require a one-time user interaction to get a refresh token, and from then on your server application can act autonomously reusing that refresh token. This is the most frequent use case, and the one that most of our examples use.

Please see our AdWords-specific OAuth guide for instructions on how to set this up.

Regards,

Mike, AdWords API Team

[Mark Jones]

Hello Mike,

Thanks for the reply.  Shortly after posting my question I did figure out that I needed to create an installed application.

For my Use Case I am going to be tracking GCLID clicks and uploading offline conversions for a client.  They have a My Client Center Account that contains many Adwords Accounts, approximately 100 Adwords accounts.  When users perform google searches and click on the advertisements, the initial click makes a request to the google ad servers which returns javascript in the response that programmatically creates a link and clicks using auto executing functions.  I am sure you know what I'm am talking about.  The GCLID is eventually appended to the end of the url of the destination landing page.  Once the landing page renders, I will be scraping that CGLID and storing it server side until I receive a notification from external processes that the particular CGLID does indeed qualify for an offline conversion.  I will then kick off some server side code that will create the Offline Conversion Feed service and try to upload the offline conversion.

One of the confusing questions for me is that of the Click Timestamp.  At what point in the request/response life cycle of clicking an advertisement from a google search does the click get tagged with a timestamp?

Does it happen at www.googleadservices.com server during the point in time when the second response returns the javascript payload that programmatically creates a link and clicks it or does it happened at the final stage when the googleadservices.com server responds with a location header to redirect to the target landing page that has the gclid appended at the end of the url?

Thanks for your help

Mark

[Michael Cloonan (AdWords API Team)]

Hello Mark,

The Click Timestamp is the time that the user clicked on the ad. Is there some reason the different timings between the two points you mention would be meaningful? They would each happen one immediately after the other, and both before the conversion would be able to occur.

Please also note that this time is saved in the time zone of the account it's associated with, so when uploading the conversion, make sure you convert the time to the same time zone as the account's time zone if necessary. This is generally a frequent cause of issues when using offline conversions.

Regards,

Mike, AdWords API Team

[Mark Jones]

Mike,

I am only trying to clarify when the click gets logged by your servers.  Is there any chance that you pass this information back to the client in the cookie or possibly as one of the url parameters?  

Thanks for the heads up on the time zone.  So if i am hearing you correctly that means i have to know in advance for every adwords account that i am tracking gclids clicks their particular time zone?  In other words, if I have a production server physically residing in Seattle, WA with time zone PST and a user in Dallas, TX performs a Google search and clicks on an advertisement where they are physically located in CT time zone, but the owner of the adwords account is located in ET timezone, I would need to ensure that when the production server located in PST receives the GCLID it would add 3 hours to the timestamp for the offline conversion?  Can you help me understand this flow better?

If i am hearing you correctly, for each GCLID you generate for a partuclar adwords account it doesn't matter which timezone the initial click originated from, because when your ad servers receive the request you give it a timestamp based on the timezone of where your ad servers physically reside, and then perhaps adjust that timestamp at a later point after performing lookups to see what timezone the adwords account physically is located?

am am making any sense?

Thanks,

Mark

[Michael Cloonan (AdWords API Team)]

Hello Mark,

To be honest, I am not exactly sure when in the process you outlined that the GCLID is recorded. The best practice for you would be to record the time that your landing page, with the GCLID included, gets visited. That is generally a close enough approximation of the time of the GCLID. Since your conversion will logistically have to happen after that (the user takes some action on the site or converts in some other manner), the conversion time will still be safely after the GCLID's timestamp.

You can look up the time zone of a customer using the CustomerService. The Customer object has a dateTimeZone field which includes this information. All time-based fields that you send to the API will be assumed to be in this timezone unless you specify otherwise. Let's say that your account is set up to use Eastern time. A user clicks an ad at 6:00 Eastern time, and the time of the GCLID is recorded as 6:00. Your servers, in Pacific time, record the page hit at 3:00 (due to the 3-hour difference). The user finishes converting by 4:00 Pacific time (7:00 Eastern time). When you upload the conversion, if you just say 4:00, you will get a CONVERSION_PRECEDES_CLICK error. You can compensate for this by either converting your times to Eastern (to match the API), or by specifying your time zone when you upload the time.

Times are uploaded in the format "yyyyMMdd HHmmss tz", where the "tz" (time zone) component is optional. If omitted, the account's default time zone is used. You can see a full list of valid time zones on our Timezones page. This is the format that the "tz" section of the date format expects.

This has nothing to do with the location of the ad servers. The AdWords account's "physical" location is also not a factor; the time zone of the account can be changed to whatever is most convenient for its users. If you reside in the Pacific time zone, then setting your account to Pacific time would be beneficial. If you do business across multiple timezones, then you would need to make sure to take these precautions.

Regards,

Mike, AdWords API Team

[Mark Jones]

Michael,

Thanks for the details - very helpful and much appreciated.

Where can i find the source code and examples for the new release?

http://googleadsdeveloper.blogspot.com/2015/03/announcing-v201502-of-adwords-api.html

https://developers.google.com/adwords/api/docs/reference/v201502/CustomerService.Customer

I checked and only see the previous builds here https://github.com/googleads/googleads-java-lib/tree/master/examples/adwords_axis/src/main/java/adwords/axis

Also, I was not aware of the CustomerService service and will have to use that because i'm dealing with multiple timezones.  Thanks for that tip.  

The client's MCC manager account holds many adwords accounts in different timezones and I will be tracking GCLID clicks for each adwords account which means I need to know the timezone of each CustomerID.  In order to know which GCLID is assigned to a particular adwords account I would need to be able to match up the landing page domain with the customer id so when i make a call to the CustomerService service I would know which CustomerID to perform a lookup against.  Do you happen to have a service that might list out the domain names assigned to each adwords account or CustomerID?  Does that make sense?

Thanks,

Mark

[Michael Cloonan (AdWords API Team)]

Hello Mark,

The v201502 versions of the client libraries and examples are in the works and should be released soon.

I do not believe that there is a way to specifically associate a customer account with a domain. Unfortunately, that mapping would have to be done at your end.

Regards,

Mike, AdWords API Team