Group: http://groups.google.com/group/adsense-api/topics
- Adsense "Link Units" [2 Updates]
- PHP Server to Server example [3 Updates]
- How do I generate Authorization header value for OAuth2? [1 Update]
- Johnny <johnnyhom@gmail.com> Mar 28 07:43PM -0700
Hello,
Thank-you for your previous help with the PHP api. I was successfully
able to extract report data using it.
I am now trying to extract data from the old Adsense interface under
the tab "Link Units." Upon my reading of the available metrics in:
https://developers.google.com/adsense/management/v1.1/reference/reports/generate
I don't see any metrics that correspond to the "link unit metrics"
such as "link unit impressions" or "link unit coverage."
Can one extract data from via the API for these "link unit" metrics?
Regards,
Johnny T. Hom
BI Apps Developer for Demand Media, Inc.
- Silvano Luciani <silvano.luciani@google.com> Mar 29 02:20AM -0700
Hello Johnny,
link units are a discrete subset of ad units, so if you know
beforehand the IDs of the ad units that are link units, you can use
those IDs to filter your report by ad unit ID.
Currently is not possible to retrieve programmatically which ad units
are link units, but that sounds like an interesting feature and we
will add it to our roadmap.
Cheers,
Silvano
--
Silvano Luciani | Developer Programs Engineer
Google UK Limited
Registered Office: Belgrave House, 76 Buckingham Palace Road, London
SW1W 9TQ
Registered in England Number: 3977902
- Eric Haskins <eric@voodoo.com> Mar 27 11:59AM -0700
Nikolai,
It appears the Service Accounts lack the credentials to act on
behalf of a user is what I am guessing and the reason that we get
noAdSenseAccount Error. So we are proceeding with the installed
Application and a refresh token path. I do not like this route because
of all people Google should understand the need for servers to be able
to communicate without the requirement of user clicking a button
especially if there are private and public keys in play. We will just
have to create a function to generate an Auth Url in the case of
accidental or unforseen token revocation.
We are posing these pitfalls and ridiculous hurdles to our Partner
Team in hopes google will make the wheel round again instead of
reinventing it square. Although the next variation will most likely be
an octagon ;-)
Eric Haskins
Voodoo.com
- Silvano Luciani <silvano.luciani@google.com> Mar 28 03:38AM -0700
Hello Eric and Nikolai,
Sorry for the late answer but I was away, and thanks Nikolai for
helping out Eric!
> It appears the Service Accounts lack the credentials to act on
> behalf of a user is what I am guessing and the reason that we get
> noAdSenseAccount Error.
Correct: Service Accounts can be used only when an end-user is not
involved, which is not the case of the AdSense APIs where you access
data on behalf of a user.
> especially if there are private and public keys in play. We will just
> have to create a function to generate an Auth Url in the case of
> accidental or unforseen token revocation.
I understand your point about automation, but the problem here is that
to access data on behalf of a user, you need their consent to do so.
Consequently they'll have to log in with their Google account to grant
permissions to your application at least once. If the application
requests offline access, it gets a refresh token that can be used to
renew the access token, so no need for clicks after the first time.
You could also set the option 'approval_prompt' to 'auto' so that a
given user sees the consent page for a given set of scopes only the
first time through the sequence.
> Team in hopes google will make the wheel round again instead of
> reinventing it square. Although the next variation will most likely be
> an octagon ;-)
I'm sorry if this is your perception of what we are doing, but I don't
think that we are reinventing the wheel.
We are implementing a specification being developed within the IETF
OAuth WG, you can find the latest draft here:
http://tools.ietf.org/html/draft-ietf-oauth-v2-25
To ease the integration of the OAuth 2.0 flow, we are developing and
open sourcing client libraries for 9 programming languages:
http://code.google.com/apis/discovery/libraries.html
I hope you'll find the above useful, please let me know if there's
anything else we can do to support you.
Cheers,
Silvano
--
Silvano Luciani | Developer Programs Engineer
Google UK Limited
Registered Office: Belgrave House, 76 Buckingham Palace Road, London
SW1W 9TQ
Registered in England Number: 3977902
- Eric Haskins <eric@voodoo.com> Mar 28 09:05AM -0700
Silvano,
I would agree if our app was for more than our publisher account
but it isn't. We are a parking partner so our systems need a way to
access only our earnings. My point is we are the programmers for
Voodoo (voodoo is a company not a person but is treated as a user) and
we are writing the systems to total earnings and reporting, if our
employer gives us access to the account and our partner team links our
Google Accounts to access it we have already been given permission. So
I see your system is great for consumer situations but it really
doesn't support partners like us. If we are pulling public and private
keys and jumping thru hoops ........ It takes less to run credit card
transactions with Authorize.net and we are only talking about
statistics. There should be a way to auth a service account to a user
account plain and simple or by virtue of the private key allow a
service account to act on behalf of the user. The user could revoke
said key at anytime if there was an issue.
We have to generate code to create auth urls on systems that usually
dont get accessed via the web like our stats farm. I know the refresh
token route but we have to plan for inadvertent or unforeseen token
revocation.
There should be a better way and I have expressed this to our Partner
Team
Eric Haskins
Voodoo.com
On Mar 28, 6:38 am, Silvano Luciani <silvano.luci...@google.com>
wrote:
- Silvano Luciani <silvano.luciani@google.com> Mar 28 03:10AM -0700
Hello Vaibhav,
Sorry for the late answer but I was away.
You can use the refresh token as many times as you want, as long as
the user doesn't revoke its validity. Every access token expires after
3600 seconds, so for example you'd need to refresh the access token
every hour if you wanted to execute the script hourly.
About your second question, it is better from the perspective of users
accessing their personal data using 3rd party applications. With OAuth
2.0 they don't have to give their username/password to the developer
of the external application, as they log in on a Google server and
then grant authorization to the 3rd party application. When they don't
want to use the application anymore, they can revoke the validity of
the refresh token.
Let us know if you have any additional questions!
Cheers,
Silvano
--
Silvano Luciani | Developer Programs Engineer
Google UK Limited
Registered Office: Belgrave House, 76 Buckingham Palace Road, London
SW1W 9TQ
Registered in England Number: 3977902
You received this message because you are subscribed to the Google Group adsense-api.
You can post via email.
To unsubscribe from this group, send an empty message.
For more options, visit this group.
You received this message because you are subscribed to the Google Groups "AdSense API Forum" group.
To post to this group, send email to adsense-api@googlegroups.com.
To unsubscribe from this group, send email to adsense-api+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/adsense-api?hl=en.
No comments:
Post a Comment