1. OIDF Social Media for Retailers SummitMarch 8th, 2011 Gary Rush Angie’s List, Inc. VP - Technology
2. Overview Objectives Angie’s List deployed Social Publishing to try to learn how much its users were wanting to share their Service Provider choices with their friends. Deployment We have deployed social publishing features in the form of facebook publishing links that publish your usage of service providers along with brief commentary to facebook Angie’s List has not deployed Social Identity features to its web site. Results Our Social Publishing feature is lightly used. Providers from categories like dog walkers or housekeepers are more likely to be shared than roofers. People are far more likely to email a profile to a friend than to publish their activity Lessons Learned Relative to Social Publishing, the demand to publish is light. It is less exciting to publish what plumber you used yesterday than what restaurant you ate at yesterday. Our demographic is very high end and older, with an average age of 50 which may slow adoption somewhat. Relative to Social Identity, we have certain requirements we are still assessing against available technologies. See needs. 2
4. Posts Information to Facebook Visual If possible, provide some screen shots They should help support the key points from the previous slide Data If you have any data you can share, please do so Increase in registrations, reduction in forgotten passwords, more complete/accurate customer data, more social publishing by your customers, more referral traffic from social publishing links, etc. 4
5. Requests 5 Seemless interaction with our join funnel. We only collect 3 pieces of data to register a customer [userid, password, zip]. The open standard should not introduce any friction into the collection of these. Even the distraction of having a choice to make as to what ID to use could create measurable friction. We will test, test, test. Any conversion loss due to “Can’t Remember Credentials” will have to be overcome by general uplift. Constant API. The API should not change very often and if it does change, there has to be lot of notice. Always Up. Our users pay us for our service. We can’t be down. Easy account maintenance. Our call center needs to be able to respond quickly. email address changes Forgot password Forgot which OpenID I used because I have several Don’t want wife to see the searches I just did Combining accounts
6. Requests 6 Publishing Control. Social has its limits. We wouldn’t want to be posting to a consumers social network their recent search for a psychiatrist or the fact that they provided a review on a psychiatrist. If we are not careful enabling activity streams, we could get in trouble Information. The more information we can get from the open ID and not need to prompt the consumer for the better. Proactive (push?) notification of updates. Our information about the user, email address in particular must always be up to date. Needs a simple way to convince the user, who doesn’t understand what is going on, that we aren’t gaining access to their credentials when we accept openID. A way out. If we commit to the standard and things don’t work out, how do we get a friendly divorce.