https://developers.facebook.com/docs/graph-api/reference/application
Is there a size limitation on Facebook App Id? How many characters will this usually be?
There is no fixed size for any ID or Token in Facebook.
Click here for source quoted bellow
Object IDs
Each node has a unique ID which is used to access it via the Graph API. We specifically do not document any node/object ID structure or format because it is extremely likely to change over time and apps should not make assumptions based on current structure.
This extends to access tokens as well.
Related
I am trying to retrieve my app campaigns and their associated apps with their events via my advertiser account.
The problem is that I am unable to find a unique identifier for my app in the API response.
For example the query below will get me the 'action_target_id'. This would either equal my AppId or another numeric string which I don't know what is. I am confused, does it mean I have two AppIds?
act_<AD_ACCOUNT_ID>/reportstats?time_interval={"day_start":{"day":"01","month":"03","year":"2014"},"day_stop":{"day":"07","month":"04","year":"2015"}}&data_columns=['adgroup_id', 'actions','action_target_id','action_target_name','campaign_name']&actions_group_by=['action_device','action_type']&format=json&async=true
What are 'action_target_id' and 'action_target_name' meant to represent (in the context of running a campaign for a mobile app)? I cannot seem to find a clear explanation for this in the API doc.
The applications/developer edge will return applications your account has access to.
As for your second question, the action_target_id and action_target_name are not always your application. It depends on what the action specs of each campaign is, if even set. An 'action spec' is a FB format for defining relationships between an ad and various objects for various purposes. More about that at https://developers.facebook.com/docs/marketing-api/intro-action-specs
In your case, the action spec in the context of a mobile app ad campaign will probably be the FB application. See also default conversion spec and default tracking spec.
I'm in the process of transitioning a Facebook Graph API integration from v1.0 to v2.0. One point of concern that I have is the original developer on this project was storing facebook user_ids in a MySQL table as a BIGINT. It appears that the app-scoped user_ids are strings. Are these numeric strings? Or is there a possibility that they would be alphanumeric thus potentially causing me a headache with this MySQL table?
According to the docs, the id field of the User object is string:
https://developers.facebook.com/docs/graph-api/reference/v2.2/user#fields
Personally, I never saw any non-numeric app-scoped Ids, but that's what the docs say.
The Developer Roadmap states in the Graph API search changes paragraph:
User access tokens will be required for all search Graph API calls except Posts, Places and Pages. App access tokens may also be used for Post search Graph API calls. Places and Pages search Graph API calls will still require an App access token. Search for Applications will no longer be supported.
But this Developer Blog Post says in the Graph API search changes paragraph:
App access tokens will be required for all search Graph API calls except Places and Pages. Search for application will no longer be supported.
So the first says that I will not need an User access token to search for posts (but I may use an App access token if I want to). And the second says that I need to use an App access token. I'm confused. Which one is correct?
There are a few things regarding the search API that I would like to mention to clear your confusion.
You can use the User Access Token for the Graph API search, for all types of nodes like Post, Places and Pages and retrieve the User's view of the result which might differ from other two cases. The difference arises basically from the permissions that other have for the respective User. I would recommend this over the others basically because the result might be more User respective.
You can use App Access token to get the Public view of the data from the Graph API Search. The data retrieved might be different or same as the other cases. Using this is a best thing to do in case of doubt over what access token is to be used.
To complicate the things further, you may even get away using Graph API search without any access token (Sample request /search?type=post&q=video). Although this is highly not recommended because Facebook might just change the API anytime requiring further changes in your app.
So in short use User Access token if you would want User view of data or if you just want public data for some statistics etc. you may use App Access token.
And to answer your question You will be required to use the App Access token after July 10,2013
With Sitecore DMS you can create Profiles and show specific pages based on the user's visiting habits. This information is stored using a cookie so whenever the user comes back they have the same visitor profile. But if they delete their cookies or switch browsers that information is gone. Now what I want to do is save this visitor information to a sitecore user, in that they can log in and their visitor profiles will be the same as when they left, no matter where they are or what browser they are using. I've been trying to figure this out for a while now but without success. Whenever I login with a user and create a specific profile, that profile is deleted as soon as i log out. Is this even possible for Sitecore, because it seems rather silly to only have profiles based on cookies when cookies are deleted constantly.
With Sitecore Analytics, you have two tracking cookies, one is for Session--the other for GlobalSession (which doesn't expire across normal asp.net sessions). Unfortunately, Sitecore doesn't track profile key scores based on GlobalSession, but by a single asp.net session. The entire system is based around this, and it's very disappointing. '
To get around this, I was using OMS and use Reflector to disasssemble and rewrite some of the analytics code to record by global session. It also required a couple of schema changes as well as new rules... pretty extensive work. At the end of the day, because of the size of the database and our need for a very limited number of features, I ended up creating a single table and recording profile key values in that by globalsession.
From what I understand, the schema has changed from OMS to DMS, but the single most important factor, that data is recorded by session, has not changed.
With regard to storing the User's id, you can associate this with a 'tag' which is stored, I believe, with the globalsessionid, at least in OMS. However, Sitecore doesn't update the tag records, so you'll end up with multiple records per global session. If you're storing this value on every request, that table will bloat quickly.
There are a couple of reasons for this... not the least of which is that in many cases, you don't have a logged in user to correlate this information with. The profile data isn't stored in cookies... it's stored in the Analytics table. But it's associated with a cookie that has a unique ID and once that has been deleted, the ID (hopefully!) won't be used again.
A suggestion for how to get around this here in this StackOverflow answer.
According this question and the official documentation on Signed Request, there should be within the encoded JSON payload a user object with an age object for the age range of the user.
However, when I decode the signature received through the JS SDK, I only have values for user_id, code, and a couple others, but no user object let alone age range. I've verified this in a stand-alone "connect" environment, as well as in a "tab application" environment. Further, when I test the JS SDK at the Test Console I see no user object either.
How can I get the user age range using just the JS SDK?
From the link
you referred,
Fields and Values
A signed_request is simply a data transfer mechanism and does not
imply any defined structure or format of data carried in the request.
However, within the Facebook Platform, the JSON object payload may
contain some of the following fields and values:
Notice the may.
There's no way you can fetch age or age range through js sdk, without
getting permission
.
p.s. I havent tested in canvas app, but in page tabs, the signed request contains the age range but only when user likes your page :)
I think you should get permission and caculate bitrthday date.