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 <https://developers.google.com/adwords/api/docs/reference/v201502/CustomerService>. The Customer object has a dateTimeZone <https://developers.google.com/adwords/api/docs/reference/v201502/CustomerService.Customer#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 <https://developers.google.com/adwords/api/docs/appendix/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 On Wednesday, March 11, 2015 at 11:42:29 AM UTC-4, Mark Jones wrote: > > 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 > > On Wednesday, March 11, 2015 at 6:10:33 AM UTC-7, Michael Cloonan (AdWords > API Team) wrote: >> >> 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 >> >> On Tuesday, March 10, 2015 at 9:15:37 PM UTC-4, Mark Jones wrote: >>> >>> 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 >>> >>> >>> >>> >>> On Monday, March 9, 2015 at 6:50:31 AM UTC-7, Michael Cloonan (AdWords >>> API Team) wrote: >>> >>>> 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 >>>> <https://developers.google.com/adwords/api/docs/guides/authentication> for >>>> instructions on how to set this up. >>>> >>>> Regards, >>>> Mike, AdWords API Team >>>> >>>> On Friday, March 6, 2015 at 3:57:43 PM UTC-5, Mark Jones wrote: >>>>> >>>>> Hello <https://developers.google.com/adwords/api/community/>, >>>>> >>>>> 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 >>>>> >>>>> -- -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Also find us on our blog and Google+: https://googleadsdeveloper.blogspot.com/ https://plus.google.com/+GoogleAdsDevelopers/posts =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ You received this message because you are subscribed to the Google Groups "AdWords API Forum" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/adwords-api?hl=en --- You received this message because you are subscribed to the Google Groups "AdWords API Forum" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at http://groups.google.com/group/adwords-api. To view this discussion on the web visit https://groups.google.com/d/msgid/adwords-api/989d4ad7-3937-4585-b20c-584885ca4181%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
