Facebook Integration – Development Secrets Revealed
In this post I am going to explain, in high level details, how you can develop your own Facebook integration. You will want to read the post on what the facebook integration provides, before you read this post so you understand what the goal of this integration is. This post is intended for developers.
First, you need to get in the mindset of thinking of one fan page at a time. If you want to expand to multiple pages then just loop over the logic. Also, the process will run several times a day. Ideally once every hour and send data each time it runs.
Part 1: Fans
To get the fan count you will want to use Facebook’s FQL. You will want to run a query like this: “SELECT fan_count FROM page where page_id=$pageId”
Once you have the fan count you will want to save it to a file ( or DB ) and upload it ONCE a day into an numeric event with the Omniture XML Data Insertion API.
To get the fan changes you will look at the saved fan count from the last time the process was run and compare it to the current execution of the process. Then you will upload the difference to give you the number of new fans since the last execution. Once you have the fan changes you will send them into a numeric event.
Part 2: Posts, Comments, Likes
This is where things get tricky. You can’t pull the number or comments or likes from the API, because the Facebook table that holds the data stores it based on the post_id. But we are lucky enough to have a created_date for the post_id.
From that you will use a query similar to this:
“SELECT post_id,updated_time,created_time,comments.count,likes.count ’ .
‘FROM stream WHERE source_id = ‘.$pageId.
’ AND created_time >= ‘.$created_time_start.
’ AND created_time <= ‘.$created_time_end.’ limit 50″}’;
You will notice in the above query that it is limiting based on the created time start and created time end. Basically, we can’t look at all posts throughout history so we need to have a limit. After a lot of testing we found that looking back 7 days was fairly safe. Yes, we will lose some likes and comments but those are far out on the long tale.
The results from the query will be based on the post_id and that is how you want to store it. You will look at the data from the last time the process was run iterating through each post over the past 7 days and comparing the number of comments and likes. Again, you will find the difference between the comments and likes (same way as you did with the fans) then upload the difference into incrementer events. Finally, the posts are a little simpler in that you look at the last saved data and if the post_id does not exist, then that means it is a new post so you increment the post counter and upload into another numeric event.
I know this is high level but the logic is fairly complex so you will need to work out a lot of the details even if I try to cover every detail I can think of.
Things to watch out for:
- You can’t pull huge sets of data from the FB API. So split it up into chunks like I did in the query above. In the end you should be executing several FQL queries for each run of the process on a single fan page.
- Facebook limits you to 100 requests every 600 sec ( 10 min). So make sure you grab the exception that is thrown when you break the limit.
- Don’t try to only run the process once a day, it is too unreliable.
I mentioned this in my last post that you can contact your Account Manager and get consulting hours with Engineering Services. If you purchase as little as 10 hours then I am confident you will save a significant number of hours of your development time not to mention the time you will save in the long term when you have a robust process in place.
As always, post your comments or e-mail me at pearcea (at) adobe.com. It is your comments and e-mails that keep me posting and give me ideas for future posts.