Facebook Audiences Explained

Every visitor to a website or Ad is an opportunity for your brand or business to re-target that visitor on Facebook.

These visitors can now have one or more Facebook (FB) Off-site pixels applied to their visit, making them available to you within Facebook for immediate retargeting. Retargeting means that the consumer sees your offer during a visit to your website and then sees another offer from you in their Facebook Newsfeed.
If you implement the Facebook Off-site pixel on your Ad or webpage every visitor will be added to the audience on FB that you have allocated this Off-site Pixel to.  You are able to form many audiences for various purposes.

The top purpose for an audience is to sell more to those that bought an offer and try to re-engage those that saw but didn’t buy. To form these audiences you should apply different pixels to consumers who bought on your website vs. those who abandoned their cart on your website. When you retarget both groups are shown different Ads in their FB Newsfeed encouraging the appropriate next action.

Extending the Use of Audiences

The Off-site Pixel Audience can be used for other offers that require a demographic audience similar to the profile of your current Off-site Pixel audience. For example, an Off-site Pixel audience is formed from consumers who saw an ad campaign about grilling and summer BBQ, they also downloaded a coupon for grilling equipment.
The same audience could be leveraged to sell a sunblock product, grilling charcoal or grocery deals.
Ads for those cross-marketed products would show up in the audiences’ Facebook Newsfeed.

Grow Your Audiences

Growing an Off-site pixel audience by 10x or more is possible once you determine that the individuals in the audience have a strong uptake.
Forming a Look-a-like Audience takes the demos and traits of your Off-site pixel audience and copies those into a new audience for you to use. 
The new audience ‘looks like’ your original Off-site Pixel audience but can be much larger.

Uptake Rates in Off-site Audiences

Uptake rates in Off-site pixel audiences are significantly better than other audience-types available.  Consumers in the Off-site pixel audience have proven that they have a level of interest in a product either through viewing it on your website, downloading a coupon, adding it to their basket or making a purchase.
This interest or purchase translates into a much higher rate of uptake when similar offers are shown to that audience in their Newsfeed on Facebook.

Evergreen Retargeting

Evergreen re-targeting creates super-audiences containing only the consumers most likely to take offers based on past behavior. This audience becomes increasing refined with every campaign by excluding any consumers who didn’t take the last offer shown to them.
This audience should be leveraged throughout the year as way to boost any new offer.


Audience cost/uptake table

How Ad Rotation & A/B testing can create advertising wins on Facebook

Ad rotation using A/B Testing is a key component to social network advertising success. This article will discuss what Ad rotation is and how it impacts advertisers.

What is Ad Rotation?

Ad rotation is the just-in-time manual or automated rotation of Ads based on conversion metrics for various sets of creative with multiple calls to action or incentives. Typically A/B testing is used to determine which sets create the highest conversions.

Ad rotation is a technique that is used by ad buyers to ensure that every dollar spent on a campaign is optimized. These tests and rotations should take place during your entire buy.

Many buyers will rotate tests multiple times a day to determine which test will see optimum results.

The experts at Marin Software, an index of over 100 Top Facebook Advertisers, found that “direct response campaigns set with ad rotation yielded 35 percent higher CTR and 34 percent lower cost per conversion than those not using automated rotation. Even more striking were the results from fan acquisition campaigns. Those with automated ad rotation saw 60 percent higher CTRs and 75 percent lower costs per fan than those without ad rotation.” Marvin, The 4 Top Facebook Advertising Trends and the Stats Behind Them

How can you execute a rotation strategy with A/B Testing?

Build a few versions of your Ad with different types of creative. Creative changes can include: moving the button, subtle changes to the call to action language, a different share image or inclusion of video vs. a static image.

Run a series of small buys using each test set of creative.  Watch the performance of each test and launch larger buys using the sets that perform the best.  Continue to rotate in the best performing sets and leverage steadily larger amounts of your planned budget to support them.

Link your Ads to a conversion pixel to track offsite events that occur.  This makes it simple to see exactly which sets are driving conversions.

The top ad rotation strategy among advertisers in Marin’s index “uses changes in CTR as a trigger for rotating creative, with 41 percent of advertisers using that technique.” Marin Software, The Definitive 2014 Facebook Advertising Playbook




Author: Carol Glennon

Open Graph Development Walk-through

Facebook’s Open Graph is a ‘structured, strongly-typed API’ that let’s your users go a step beyond a Like or share.
Open Graph (OG) allows users to form a Story from actions that they take around Objects.

The OG API packages up Actions and Objects into posts that read like a personal account of an experience.
Open Graph brings a conversational tone to the staccato chatter of Likes and shares.


This article is a quick start for people who want hands on information about OG but it is not intended to be a comprehensive guide, FB has lots of those ready when you are.

What Makes Up an OG Story
Stories are made up of Actions and Objects tethered together by the App that the story was spawned from.

The parts of an Open Graph Story

Open Graph Standard Action Types
Facebook has established standard Action types and groups of related Actions.  They cover most anything but if they don’t cover what you need keep reading, we go over custom Actions types further down.

Standard Open Graph Action Types

Testing with a Standard Action Type
Use the Graph API Explorer to easily test all of the standard Action types. Begin by creating a basic test App to use.
Be sure the set the necessary rights for a given Action when grabbing the token. For example, if the Action is Post then the rights will require Publish_Actions rights.

Test Posting an Action with the Graph API Explorer

Browse the ID returned from your test to see the Story components.

Creating a Custom Action
Creating a custom Action is easiest via the New Story option.

The New Story wizard allows you to use existing Actions, make a new one on the fly and select the corresponding Object type easily.


After creating the Action and Object in the wizard look in the Stories panel for the Get Code option.
This option will give you the Object code (to be embedded in the <head> of the HTML) and the URL POST action to make the FB OG API post.

Debugging Objects
The OG meta properties are critical to the Custom Action working properly.
It can be helpful to debug your Object page to be sure that all of the OG meta properties are in place.

Custom Action Weirdness
Custom Actions are tricky to debug prior to approval.
There is a known FB API bug that prevents custom actions from committing to a user’s feed, even if you are using a test user.
Do not despair, if you try to test and get a “Try your request again later. OAuthException Code 2” response then you are encountering the bug the prevents Custom Actions from being committed before the App is approved!
You can see this link for more info on the bug.
To get around this test your Custom Action using the GraphAPI and you will instantly see a proper ID for the Story returned.


OG Auth From the User Perspective
Giving OG permissions is painless for the user.
FB handles the opening and closing of the user permissions dialogue as well as all content in the window.


Good luck with your Open Graph adventures and remember, don’t get discouraged by the OAuthException, just test with the GraphAPI explorer and submit your app for approval.

Author: Carol Glennon

An Easy, Homegrown, GitHub Issue Management System for Your Developer Outreach Efforts

Do you need to know what issues devs are having with your API or platform in near to real or real time?

Does your team have a platform, API, BaaS or other solution that calls for community developer involvement and developer outreach/evangelism through GitHub? 

Do you need to be responsive to developers that file issues about your product in your Github repo?

If you answered “Yes” to any of the above then this GitHub Issue response system tutorial is for you!

This tutorial will take you through the steps to set-up a multi-layered way to manage incoming Issues via GitHub.  Multi-layed GitHub-driven Issue alerting accelerates the break/fix process and eliminates bottlenecks by getting information into multiple points in the Agile cycle. The system outlined here makes your Agile team as responsive as possible to every incoming GitHub Issue for a given repository.

This system puts developer feedback instantly to work for your team by getting critical feedback into your Agile workflow in all the right places: during planning via a Pivotal Tracker new Story and text message, during testing via a new Zendesk Ticket and post-release via a Ducksboard heads up display.

This type of multi-layed response let’s developers know that you are listening actively and it gets valuable developer feedback into the hands of multiple members of your team quickly so that it can be acted upon quickly and iteratively, the way Agile was designed to.

This tutorial uses the following: a GitHub repository, Zapier, Ducksboard, Zendesk and Pivotal Tracker.

You can choose to use the whole system or just the parts you love, it’s up to you. GitHub and Zapier are the only items that are definitely required for this tut and for the most part they are both free.

Follow the steps and at the end of the tutorial you will have a system that takes an incoming Issue from a GitHub repo and then:

  • files a new Support ticket to your Zendesk account
  • sends a text message to a set of phone numbers like your PM or developer evangelist
  • files a new Bug in your Pivotal Tracker to be triaged (if you use Agile)
  • makes a post to a Ducksboard heads up display wallboard

Step 1

Turn on Issue Tracking for the GitHub repo that your open-source code or SDK reference material resides in. Turn on Issue Tracking by going to your repo and then go to Settings -> Features -> check the box to allow Issues.

After enabling the Issues feature the Issues option will appear for all users as a top level tab next to Pull Requests and Wiki.

Step 2

Let’s get the part working that opens your Zendesk ticket, files a Pivotal Tracker Bug and sends a text message (aka SMS) to some mobile numbers.

Set-up an account (it’s free) at Zapier.

Have your GitHub, Pivotal Tracker and Zendesk account pages open and handy so that you can grab authentication details.

Set-up an account with the SMS folks at Mobyt.com, make a new campaign while you are there, name it anything you’ll remember, pick a keyword it can be anything, check off the “MO” box under the Keyword field. Keep the user/pass handy.

Now for the fun part!

Create a new ‘Zap’ on Zapier by finding GitHub in the services marketplace and dragging the GitHub icon into the box on the left. Click the New Issue trigger from the GitHub trigger choices.

Find the Zendesk icon and drag that into the box on the right, select Create Ticket as the action.


Click Create This Zap. The page will set-up forms to collect your auth details for the GitHub side and then the Zendesk side.

In Section 2 drag in the fields from the left that you’d like to populate the new Ticket with.

Scroll all the way to the bottom (don’t worry about Filters or Tests right now) and click Enable.

You’ll land on your dashboard page and see the new Zap live under the Live Zaps table.

Click Create New Zap and run through the same process again but this time use GitHub New Issue on the left and drag Pivotal Tracker over onto the right. Choose New Story for the Pivotal Tracker action.

Enter the auth info for your Pivotal Tracker account. Scroll down drag in the fields from the left that you’d like to populate the new story with and Enable the Zap.

Now the last Zap!

Click Create a New Zap. Drag GitHub to the left as with the previous two, drag Mobyt SMS onto the right. Choose New SMS as the action.


Drag the Mobyt SMS icon into the right side of the Zap and select New SMS as the Action.

Add your authentication info for Mobyt.

Decide what fields you need the people getting the text message really need to see. I normally use the Title and Body.

From the dropdown on the Mobyt side, select the keyword that you set up earlier, it should be the only one there at this point.

In the Recipient field enter the mobile phone number that should get a text message when a new Issue is filed.

Just enter one to get this going, you can add more later once you know it’s working the way you want it to.


Select the Campaign and Keyword that you set up when you opened the Mobyt account. It will be the only option in the list.

Head over to GitHub and file a new Issue in your repo.

Open up your Dashboard on Zapier. All of your services should be Live, not Paused.

Click the gear to open up the menu for each service.

Click Run for each service.

Zapier Run

Click the Run icon to run your new Zap and test it.

After running each service you should see a new Ticket filed over in Zendesk, a new Story filed in Pivotal Tracker and a new text message arrive on your mobile phone.

This next step will allow you and your team to see all of your GitHub Issues in real-time on your heads up display. 

Ducksboard is a versatile real-time dashboard visualization web page that can be displayed on a monitor, a TV or you can link to your Ducksboard page from your Intranet, site or Wiki.

Here is an example of a sample Ducksboard that is displaying recent issues from GitHub, a list of a repo’s followers and some info from Pivotal tracker.

Ducksboard Example

This example is a Ducksboard that shows GitHub Issues, Followers and Pivotal Tracker actions for a given repository.

To use GitHub with a Ducksboard just head to Ducksboard and create an account, there are plenty of free and trial options.

Click the + sign on your first board and scroll around to find the GitHub widget.

Pick the GitHub Issues group then select GitHub Issues, One Column/Two Rows.

After authenticating click Choose Content from the tabs on the left.

Add your GitHub username and the name of the repo where you turned on Issue Tracking.

Save the preferences for that widget and presto, your Ducksboard will begin loading the issues from the repo.

You can add other widgets to the Ducksboard and then share the link with folks on the team who need it or add it to a wall board on a TV etc.


We just created a new Ticket in Zendesk, a new Story in Pivotal Tracker, a text message and a heads up display all from a single new Issue filed on GitHub!

Author: Carol Glennon

Intro to Agile for Engineers (Agile for EE)

This article is an overview of agile development basics, including common terms and processes, used during the agile development process. The overview will help engineers understand the agile elements and stages and have a basic understanding of how the agile process identifies and then delivers a work product.
This is an important overview for engineers that want to understand and communicate effectively with their software counterparts in teams that are employing agile processes such as in partner groups or customer teams.

Agile is set of development methods and recommended processes that strive to deliver higher-quality, ‘shippable’ products through iterative and incremental cycles.
Agile development emphasizes on-going evaluation of features to be built, constant streams of feedback, daily interaction, cross-functional teams and self-selection of work items.
The Agile Manifesto, written in 2001 by agile method pioneers, outlines the importance individuals, interactions, working software, collaboration with customers and responsiveness are to the methodology.

The Agile Manifesto reads, in its entirety, as follows:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”*

*Agile Manifesto Copyright 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn,
Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern,
Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
This declaration may be freely copied in any form, but only in its entirety through this notice.


Agile development benefits from working, ‘shippable’, product at the end of each iteration. The work product at the end of each iteration has undergone continuous testing and feature iteration and is ready for production use. Product owners and stakeholders are able to build upon working pieces from each iteration and quickly prioritize features for the next iteration without delay.
A total understanding of the work at hand and constant communication with development, stakeholders, product owners and quality assurance provides cost-savings as expensive delays and testing mishaps are avoided.

Agile Cycle

The agile life-cycle begins with stakeholders and product owners determining what features are possible candidates for inclusion in the product. Product managers leverage stakeholder input to write epics, epics are large user stories that need to be broken down into smaller pieces of work. After an epic is broken down into stories, the stories are prioritized and maintained in a backlog. The backlog is an aggregate of stories pending inclusion in an iteration.
Release planning, iteration planning and daily planning provide iteration teams with the product features that they will work on during iterations.
During release planning developers make estimates about the level of effort required for stories, define what stories will be included in each period of iteration (periods of iteration are known as ‘sprints’ when using an agile scrum methodology).
Aother work product of the planning phase and pre- develoment are test unit cases, these are small unit tests that are written and completed by a developer before beginning work help to increase the quality and accuracy of subsequent code.

Agile Process Stages

The agile process can be implemented in a variety of customized formats. A hallmark of most implementations is requirements gathering and creation of epics and their resulting stories. These become the cornerstone for release planning.
Iteration planning and the backlog go hand in hand as items are pulled from the backlog to be included in a specific iteration or sprint if using scrum methodology.
Estimation is an important part of always improving the iterative process. In the beginning agile estimates can be off the mark but with good practice of iteration retrospective techniques (see next paragraph for more on iteration retrospective) teams learn to estimate well in time.
As the iteration progresses you may hear the term ‘burndown’, this refers to the stories or tasks that have been accomplished so far in an iteration. Items completed and reflected in burndown reports should be demonstrable and shippable.

Agile Testing, Iteration

Testing is an important part of the agile process. Test driven development means that small unit tests are written and manually run by developers right before development.
Automated unit testing enables tests to be written and then performed by software programs designed to test and provide reporting on the results.
Development in agile is continuous, with shippable code being produced constantly. Testing throughout the process vs. just at the end of development, ensures that the iteration is maximized and errors, issues and bugs are found very early on.
At the end of an iteration there will be an interation review, this review is typically an informal demonstration of the working, shippable, code product accomplished during current iteration.
Another goal marker for each iteration is the iteration retrospective. During the iteration retrospective the entire iteration team inspects it’s process and reviews issues that arose during the iteration. Estimates are compared to actual burndown progress to determine the level of accuracy. every iteration attempts to increase estimate accuracy rates. The review is a time to openly determine what worked and what didn’t. The entire team commits to making changes to improve the next iteration.

Agile Methodologies

Agile implementations and methodologies come in many formats. Your organization or your customer’s may use a very traditional implementation or you may see a hybrid form of scrum being used. Whatever the method, the goal of agile methodlogy, a working, shippable product at each iteration, remains.
There are many sources of information to take your agile knowledge to the next level. Courses and certifications in the various aspects of agile are prolific. You can find more information on agile through the Agile Alliance.

Author: Carol Glennon

Managing Lights and Plugs Made Easy for Developers With Taapi’s API

“…Taapi is gamification at it’s best.” Wired 
“The game is the first global, mobile gaming platform that will have a significant impact on the real-world.” OpenSocial.org

Taapi provides the first, open-source, global, all-purpose energy management API for developers.  

We believe that users should be able to control their light and wall sockets from their favorite applications and that app developers and game builders should be able to incorporate light and wall socket controls into their applications.
Managing lights and plugs has typically been an expensive, proprietary domain using closed source systems. Producers of light and wallsocket controllers do not allow wide developer access to their products in the home or integration of their in-home products with third-party applications.

How Taapi Works
We build wallsocket adapters and smart lightbulbs that operate using a commercial-grade protocol and low-energy WiFi chipset.
Through our smart bulbs and wall socket adpaters we create secure communication between lights and wall sockets to power lights and sockets on and turn them off.
The Taapi systems handle authentication of users devices, auth of user ID’s in your apps via OAuth and creating a completely masked identity for a user’s devices for security.
Taapi also maintains a constant record of state that recalls the state a socket or light was in when it was acted upon by Taapi. Maintaining states ensures that the light or wall socket can be returned to it’s original state when a user wants to regain full control of their lights or wall sockets.

Taapi employs commercial-grade standards in it’s open-source APIs.

Multiple devices can be run off of a Taapi wallsocket.  Lightbulbs can be used for hardwired lights, like overheads.

Taapi creates local WiFi communication between sockets and bulbs by using a hub that connects to your router. The hub communicates securely with the Taapi service and the light’s owner. The Taapi service exposes REST services to developers.

Taapi Cloud Services for Developers

The Taapi Cloud and Service Paths

Easy Integration for iOS, Android and OUYA Enabled Games

Integration with Taapi is optimized for speed and ease of set-up.
Libraries for iOS, Android and a rapid-setup, special build set of classes for OUYA will be available to developers. Integration with Taapi is optimized for speed and ease of set-up.

The Taapi Social Game
The Taapi API is now used to power a social game where unused lights are added to a pool of anonymous lights waiting to be turned off. Players race to turn off lights as they are added to the pool. This game leverages many parts of the API such as session establishment, auth and lights and plug management.
The first Taapi game is available on iOS, Android and the OUYA game console.

The Taapi Social Game

What will the Taapi API offer developers?
Taapi manages the heavy lifting that devs typically associate with environmental controls: hardware, normalization, security, WiFi protocols and local network authentication
We manage those pain points and provide the dev with a manageable API that they can leverage as the dev, and their users, see fit.
Taapi has tools to provide access to a range of game and app developers by providing a full REST API with hooks that can programmatically act on Taapi’s services from your app or service.
The Taapi API will provide access for app and game devs to features such as:

  • Adding new players
  • Authenticating players
  • Calling player stats
  • Calling general country, energy, and date stats
  • Initiating a race session
  • Obtaining the stats for a unique race session
  • Polling for available races

Taapi has selected Atlassian (http://atlassian.com) products for community support, Mashery (http://mashery.com) for API hosting and Taapi has built-in an OpenSocial container for developers to write gadgets for Taapi using the OpenSocial (http://opensocial.org) standard.

Taapi’s OpenSocial container support will allow developers to quickly and easily write OpenSocial compliant gadgets that can call and serve a number of Taapi features like public Taapi use statistics, aggregated stats, individual users stats and game session availability.

The Taapi OpenSocial container will support gadget authentication via OAuth to enable personalized, contextual player information and interaction as well.  Players will be able to add approved gadgets to their instances of the Taapi game and extend Taapi’s functionality.
For example, a developer could write a ‘My Country’ Taapi gadget to alert a player when a session in a specific country is available, authenticate them, opt them into the game session and tweet about their participation, all in that country’s native language(s).

Taapi founder Carol Glennon states, “Support for an accelerated development process was one of our top goals for the Taapi platform. Enabling gadgets through our OpenSocial container makes it easy for developers to gain fast access to our API while writing cool gadgets that users can use in Taapi right away.”

Access to the Taapi API will also be available on Zapier, a service that syncs many different web apps. A developer can use Taapi and Zapier to initiate a number of web actions for example, setting a block of time that lights should be turned off for a user when they schedule a calendar event in the devs application.

Taapi Partners and Community Services for Developers

We Are Counting on YOU
We need your support as a backer now to produce the lightbulbs and wallsockets that will be used in thousands of your users homes and offices.
Enabling us to produce our home kits provides you as a developer with an ever-widing pool of users that are ready to use Taapi with your app and games.

Please come and back us today and pick a great reward. It’s inexpensive, fast and will benefit your app or game greatly.

Taapi Team Experience
The Taapi core executive team have been working on projects together for over a decade and have experienced amazing success in that time. Together, they have a pretty cool history of ability to deliver amazing experiences. Examples of previous work includes delivering mobile apps, games as well as cutting edge and complex 3D animations and solutions for major consumer-focused companies including Time Warner, Intel, CBS, California Tourism, Delta Airlines and National Geographic.

We have been recognized and received over a dozen National and International awards for our work and have been at the cutting edge of technology for a combined four decades.

2012 National Geographic Kids Almanac
2011 Visit California iPad application
2011 San Francisco Giants and Safeway2011 San Francisco Giants and Safeway
2011 MLB, 7Eleven and Frito Lay
2010 Stevie award – Most Innovative Company  of the Year
2010 World Cup through FIFA backed 1Goal
2004 Who Wants To Be A Millionaire U.K. (mBlox)

Author: Carol Glennon

OpenSocial Overview, part 2

The OpenSocial gadgets specification includes multiple APIs that make it easy to authenticate users and access data and core functions on participating social networks. We featured an OpenSocial infographic here as part of our two-part shout out to the folks at OSCON.
Platforms that have OpenSocial compliant application containers can run OpenSocial gadgets, sometimes called ‘plug-ins’. Some of the companies that support OpenSocial plugins in their public environments are: Atlassian (known for JIRA, Confluence and other great systems), SAP, IBM, Salesforce.com, SugarCRM, Yahoo!, Google and many more. These platforms run Apache Shindig to create the container that supports OpenSocial gadgets. The evolution of Shindig is Apache Rave. See the end of this post for more on Apache Shindig and Rave.

This sample will demonstrate a sample of a formed XML gadget descriptor and a live-test. Every gadget is made up of an XML descriptor that calls on functions that the Apache Shindig server supports.

Step 1. get the sample.
In this example we give you a sample XML gadget descriptor here: XML Gadget Descriptor. Download and save it if you want to try the test yourself and have a code sample to alter later.
The main function areas of this sample are: module prefs, user prefs, get and display. The entire OpenSocial gadget specification is here. (Updated, now 2.5)
This sample calls and displays a feed of news articles and relies upon the gadgets.io.ContentType.FEED function.

Step 2. decide to host the sample or use our URL.
Either download the XML sample and place it on a publicly accessible URL of your own or use our URL in step 4 of the demo.

Step 3.  test the sample live.
Testing your XML Gadget descriptor is important.
Yahoo! has a sandbox for live OpenSocial plug-ins and it only takes a couple of minutes to set-up. Head to https://developer.apps.yahoo.com/projects and sign up for a dev account, don’t worry-it’s free.
Log in and head to “My Projects”, select “New Project”, choose type “YAP” (Yahoo! Application Project), select “Import New XML”.
Either paste in your own URL that points to the XML sample you downloaded in Step 1. or point to our sample URL, select “Import”.

Step 4. Preview the sample.
Select “Preview” to view the sample as a formed gadget. This is how your gadget will look for users.

A couple of notes about testing with the Yahoo! live sandbox, Yahoo requires a category parameter and value in the module preferences. Without the category parameter the descriptor will generate errors.  You can remove this parameter after testing if need be.

 title="Google Gadget Dev News"

Here is an example of this OpenSocial example gadget in the SAP StreamWork application.

Example gadget in SAP Streamwork application

You can use OpenSocial to deliver many types of social data to your users quickly and easily as well as authenticate them for interactions with social data. Customizations and functions for the OpenSocial standard are extensive and growing.

Here are a few ways that you can get started:

View a tutorial.

Become  an “OpenSocial container” by using Apache Rave to host social apps.

Contribute to the evolution of the OpenSocial specification or become an OpenSocial Foundation member.

Follow @opensocial.

Author Carol Glennon