"ЭйПиАй, ЭйПиАй, кого хочешь выбирай"
19 Jul 2013Думаю, в штате каждой крупной социально-сетевой площадки сегодня имеется Data Science Team. Эти ребята регулярно выкатывают на-гора результаты своих исследований -- каскады распространения сообщений в социальных сетях, теории шести - пяти - четрех (кто меньше?) рукопожатий и прочее прочее. За работой одной из наиболее знаменитой Data Science Team можно следить здесь.
Естественно, у многих исследований возникает желание повторить их результаты или проверить собственные гипотезы. Ведь это же так удобно -- пользователи сами уже предоставили о себе достаточное количество информации. Надо только взять ее и проанализировать. Как написал журналист The New York Times, "...Facebook’s role as a petri dish for the social sciences — sociology, psychology and political science — that particularly excites some scholars…".
После первого опьянения от кажущихся возможностей наступает неловкий момент столкновения с реальностью. Какую информацию о пользователях и в каком объеме соцсети готовы отдать сторонним исследователям? Это зависит от проработанности API каждой социальной сети.
Сбор данных через API ("ЭйПиАй") -- application programming interface -- набор классов, процедур и функций от администрации социальных сетей для использования внешними разработчиками -- является наиболее "правильным" (с точки зрения ToS) и наиболее удобным в плане проектирования "сборщика данных".
Но каждая социальная сеть накладывает на свой API ряд ограничений, с которыми приходится считаться. Ниже представлен крайне субъективный рейтинг популярных в России и мире социальных сетей по возможностям, простоте и доступности их API. Все оценки, мысли и выводы сделаны с точки зрения потенциального исследователя, которому хочется насобирать свой кусочек той самой Big Data и провести свой маленький research. В основном, это описание личных впечатлений от работы с API, кое-где "humble opinion" разбавлено выдержками из официальной документации. Для нетерпеливых -- в конце есть сводная таблица.
1. ВКонтакте
На мой субъективный взгляд родной ВКонтакте -- явный лидер этого рейтинга. Смотрите сами:
крайне богатый набор методов;
несложная регистрация приложений;
ограничение по количеству запросов -- 3 запроса в секунду (sic!);
типично российское отношение к вопросам приватности: показываем все, что пользователь специально не запретил.
Эго-сеть пользователя, набор интересов, его участие в сообществах, и -- вишенкой на торте -- в сети ли пользователь в настоящий момент (метод users.get, поле online ).
Потенциальным исследователям остается только придумывать, как использовать открывающиеся возможности.
И не забываем про число пользователей -- все-таки самая популярная соцсеть в России. Т.е., исследовательского материала -- только успевай обрабатывать.
Небольшая ложка дегтя -- по итогам работы с геолокационными вызовами (методы класса places) мне показалось, что данный функционал как-то не до конца продуман в рамках всей соцсети. И с ходу получить оттуда интересные данные не получилось.
2. Twitter
Вопрос о том, является ли Twitter социальной сетью, оставим для теоретиков. Для нас интересно то, что данная площадка дает редкую возможность понаблюдать за распространением информации в реальном времени. Каскады ретвитов, теории заражения -- есть, что изучать.
Регистрация приложений доступна здесь. После создания приложения есть удобная возможность создания "авторского" access_token'а, упрощающего процесс авторизации при работе с API.
API сети принципиально делится на две больших категории: "традиционный" REST API и Streaming API. REST API позволяет получить практически всю информацию, доступную рядовому пользователю (списки подписчиков, друзей, историю сообщений) через GET или POST запросы. Есть только две небольшие проблемы:
достаточно строгие ограничения на количество запросов (зависит от метода, для популярных запросов -- 1 запрос в 5 секунд);
минимум характеристик отдельных пользователей (возраст, место жительства, интересы -- все это не для Twitter).
Вторую проблему необходимо просто иметь в виду при построении дизайна исследования. А с первой проблемой можно попробовать бороться, используя Streaming API. Данная категория методов позволяет "подключаться" к потоку сообщений в реальном времени и фильтровать свой персональный поток на основе авторства, ключевых слов, местоположения, хештегов. Временные ограничения отсутствуют, но лимитирован объем потока -- не более 1% от публикуемых в данный момент сообщений.
В середине июня Twitter API обновился до версии 1.1 и окончательно перестал поддерживать вызовы версии 1.0. Основные итоги обновления:
окончательно отменили HTTP Basic authentication (ранее работал в Stream API) -- это запишем в минусы;
заблокировали недокументированный вызов activity/summary.json -- еще один крупный минус;
значительно расширили возможности методов search.
Появилась возможность фильтровать поисковые запросы по авторству, дате, адресату и пр. В итоге, обновленные методы search вполне заменяют и методы timeline, и вызов activity/summary, что нивелирует эффект от блокировки старых методов.
3. Facebook
Корпоративная культура соцсети пронизана духом "хакерства". "Построим что-то быстро, выйдем за границы существующего"; практика многодневных "хакафонов". Все это с восхищением описывается в современных статьях по менеджменту. Однако мало найдется комментариев, посвященных обратной стороне хак-подхода: отсутствию системности. Эта проблема хорошо заметна на примере Facebook API. Несколько реализаций (основные -- Graph API и FQL, которые не дублируют друг-друга лишь частично, не являясь полностью взаимозаменяемыми); недоступность некоторых вполне очевидных функций (попытки получить списки подписчиков публичных страниц обсуждаются на stackoverflow с 2010 года, но актуальность проблемы не снижается ). Возможно, именно благодаря этому Facebook API заработал в 2011 году звание худшего. Я скорее не согласен с этой точкой зрения (так и хочется сказать "зажрались"), но доля истины в этих оценках, несомненно, есть.
Из плюсов:
Сравнительно простой процесс создания и регистрации приложений.
Приличные ограничения на количество запросов (официально не описаны, но по экспериментальным данным -- на уровне одного запроса в секунду.
Объемная документация и песочница.
4. Instagram
"Младший брат" Facebook обзавелся API в 2011 году. Регистрация приложений, как и в случае других соцсетей, требует наличия пользовательского аккаунта. Но вот сам пользовательский аккаунт без дополнительных ухищрений могут завести только владельцы iOS и Android устройств. Blackberry, Windows Phone и прочие Meizu остались за бортом.
Почти как у Twitter'a, у Instagram есть вариант с предоставлением данных по запросам (аналог REST API) или с подключением к обновлениям в реальном времени (аналог Streaming API). Небольшое "но" -- для real-time обновлений используется механизм обратных вызовов (callback), а значит понадобится соответствующая настройка собственного клиента и выделение ему постоянного адреса.
Подробнее про REST API: ограничение по количеству запросов -- 5000 запросов в час; аутентификация -- по протоколу OAuth2.0 (как и в Facebook, Twitter, ВКонтакте); группы методов позволяют получать информацию о связях, местах (геолокация), размещаемых фотографиях, "лайках" и комментариях. Вроде бы все здорово, но начинаешь работать, и понимаешь, что там что-то забыли, а тут вообще решили недоделывать. Например, попробуйте с помощью методов comments вытащить более 150 комментариев к популярным фотографиям. Не выйдет. И никто не знает, как выглядят оставшиеся (total - 150) откликов и есть ли они вообще. Хотя, возможно, с идеологической точки зрения это и верно -- кому нужен текст, когда вокруг столько визуальной информации. Да еще и с такими хипстерскими фильтрами.
5. LiveJournal
Вроде бы не совсем соцсеть, скорее блог-платформа. Но как можно пропустить это знаковое для рунета явление?
Как такового разработанного API у сервиса нет, но администрация не запрещает работу ботов, пауков и спайдеров -- при условии соблюдения ими ряда требований. Одно из требований касается ограничения количества одновременных запросов -- не более 5 в секунду. Вроде бы не так уж и мало, но ответы приходят не в ставшем уже стандартом "экономном" json-е, а в xml-образных FOAF, RSS, а то и html.
Зато не требуется специальная регистрация приложения и аутентификация при обращении к сервису. Также на сайте есть набор полезных ссылок для сторонних разработчиков, где можно попытаться найти подходящие примеры и документацию. В целом -- жить и работать можно. Но впечатление погружения в прошлое не покидает.
Маленький совет при сборе текстовой информации (посты и комменты): параметр format=light при GET запросах унифицирует структуру .html страниц разных авторов, а внутри документа спрятан json-фрагмент с комментариями пользователей. В итоге полное дерево комментариев сравнительно легко парсится с помощью двух рекурсивных функций.
6. Одноклассники
Ох. Что тут сказать... Нет, у них есть API. В принципе. Вроде как. Но исследователей они явно не ждут. Эту социальную сеть интересуют только те, с кем можно заработать денег. "мин. 2000 одновременно играющих пользователей, добавление 25 000 новых в час, более 250 000 запросов картинки 128х128 одновременно" -- так будут выглядеть минимальные требования к вашему серверу, если вы вдруг решите официально зарегистрировать свое приложение. При этом даже формально процесс этот будет непрост. Сначала регистрация в task-manager'е Jira, потом -- "песочница". И если все хорошо -- одобрение от администрации. Тот еще квест. Вдвойне обидно из-за того, что в сети есть жизнь. И ее много -- все-таки вторая по популярности сеть в России.
Гипотетически настырный исследователь может попробовать в обход API парсить напрямую сайт социальной сети. Однако, во-первых, пункт 7.4.2 ToS это прямо запрещает, а во-вторых, любая автоматизация при сборе данных будет осложняться динамической адресацией внутри сети.
7. Foursquare
Хорошая сеть. Интересная для исследований. Соединение виртуального пространства и реального, физического. Есть за чем понаблюдать. И API неплох. На уровне аналогов. Простой процесс регистрации приложений, аутентификация через OAuth, основной API реализован через GET-запросы, есть экспериментальный Real-time API, но проку для исследователя от него пока мало. Наиболее интересные и информативные методы -- группа venues. Для одного приложения ограничение на количество запросов -- 5000 в час.
Но самая большая проблема сети -- не эти ограничения, а чрезмерная озабоченность вопросами приватности. В сети практически невозможно получить какую-либо информацию о незнакомых пользователях. Просто найти их уже проблема, а уж узнать что-то больше имени практически невозможно. Еще год назад можно было хотя бы через метод venues/herenow узнавать, кто сейчас в заведении. Последовательно обходя список популярных мест, можно было отслеживать "миграционные потоки". На сегодняшний день такой вариант исключен: "увидеть" пользователей через этот метод можно только если они ваши друзья или друзья друзей.
Что-то большее можно получить только с привлечением сторонних сервисов. Например, если пользователь транслировал свой "чекин" в Twitter, то, используя код из твита, можно получить доступ к его чекину через API Foursquare. Такой способ потребует написания приложения с участием, как минимум, трех сервисов: Foursquare, Twitter и BitLy (используется для извлечения кода). И все это должно будет работать согласованно. Тем не менее, задача эта решаемая, а результат, на мой взгляд, стоит усилий.
8. Google+
Популярная шутка: "Если у вас есть аккаунт в Google+, вы либо сотрудник Google, либо робот". По официальным сообщениям, эта сеть бьет все рекорды по скорости прироста пользовательской базы, но более внимательный взгляд показывает, что активность пользователей в сети сильно ниже того же Facebook.
Тем не менее, сеть есть, и в ней есть какая-то жизнь, которую можно понаблюдать -- как минимум для того, чтобы сравнить с другими. API всех сервисов Google собран в одной достаточно удобной консоли. Во вкладке Services включаем нужные сервисы. Очень удобный для исследовательских целей режим "Simple API Access". Если нам не нужны приватные данные отдельного пользователя, такой режим нам вполне подходит. Прямо из консоли создаем API key, который заменяет все заморочки с аутентификацией запросов. Просто добавляем соответствующий параметр в GET-запросы.
На ресурсах Google особо не экономит. Так что ограничения по количеству запросов можно считать чисто символическими. 5 запросов в секунду на пользователя для обычных запросов, 250 (!!!) для подписанных.
API позволяет собирать информацию об общедоступных данных о пользователях (методы People ), их записи в сети (Activities ) и комментариях. Достаточно скромно и лаконично, но все самое необходимое есть. Если бы еще Google не прятал "по умолчанию" основную часть персональных данных...
9. YouTube
Является ли YouTube социальной сетью? Как и в случае с Livejournal, это тема для отдельного разговора. Главное -- тут есть пользовательские аккаунты, возможны связи в виде подписок друг на друга и комментирования привлекших внимание роликов. И эта коммуникация в комментариях порой поражает воображение.
Доступ к API оформляется в той же консоли, где и Google+. Более того -- часть про Simple API Access с одним постоянным ключом в данном случае также актуальна. Идеологически ответы API организованы в виде потоков -- feeds. Есть потоки с видео (либо запрос на поиск, либо видео с определенного канала), потоки с подписками и плейлистами пользователя, потоки с пользовательскими профилями и комментариями к видео. Все потоки основательно и с примерами описаны в документации. Из интересного: json-ответы довольно странно оформлены (по сравнению с тем, что отдают другие сервисы). Но к этому быстро привыкаешь. Еще из сложностей -- ограничение на максимальное количество комментариев: около полутора тысяч -- в 10 раз "круче", чем Instagram.
Из специфических "приколов" YouTube -- "фирменный" механизм расчета лимитов на количество запросов. По ключу количество запросов ограничено тридцатью тысячами "юнитов" в секунду. Но один запрос не эквивалентен одному "юниту". Более того -- требуемое количество "юнитов" для всех запросов разное. Ориентируясь на примеры из документации, можно сказать, что на один запрос на чтение списка видео требуется около 10 "юнитов". В любом случае, в пересчете на запросы это очень много. У меня полностью выбрать такие лимиты не получилось. Может быть вам удастся?
10. Вместо заключения
Долго придумывал, кого бы взять десятым номером для "красоты картинки". "Мой мир"? LinkedIn? Wikipedia? Но все эти варианты были бы не вполне честными. Как-то так получилось, что с крупными задачами в рамках этих социальных сетей я ни разу пока не сталкивался, а описывать их возможности просто по официальной документации, наверное, не совсем правильно.
Другим действительно классным кандидатом мог бы стать Social Graph API от Google. Только подумайте -- везде выше мы рассуждали о пользователях в рамках только одной сети как относительно автономной сущности. Но ведь это не так. Если вы более-менее регулярно пользуетесь интернетом, могу поспорить, что аккаунтов в социальных сетях у вас больше, чем пальцев на руке. И коммуникация вместе с информационными потоками не ограничена одной соцсетью. Т.е. ваша виртуальная социально-сетевая сущность есть совокупность аккаунтов сразу в нескольких социальных сетях. Именно такие совокупные виртуальные сущности позволял исследовать Social Graph API. Но, как и многие другие интересные, но непопулярные проекты поискового гиганта, сервис был "похоронен" в январе 2012 года.
Так что оставим пока "великолепную девятку" и попробуем перевести в баллы и оценки все сказанное выше.
Вот такой получился субъективный рейтинг. Второе и третье места Google+ и YouTube даже для меня стали неожиданностью. Пользуйтесь, но не забывайте, что правильное исследование основывается на постановке вопроса и формулировании существующей проблемы, а не на удобстве интрументов.
Sincerely Yours,
Alexander "Sobach" Tolmach