Помимо b2c проекта Surfingbird в нашей компании есть b2b продукт Relap. Это рекомендательная система для медиа. Вы могли видеть нашу технологию в действи на Лайфхакере, AdMe, РИА, COUB и других сайтах, которыми пользуетесь каждый день. Мы помогаем клиентам вовлекать аудиторию в потребление контента, с помощью алгоритмов, которые разрабатывали несколько лет.

Мы часто сталкиваемся с заблуждениями и мифами о том, какими должны быть рекомендации вокруг основного контента, за которым приходит юзер. В статье рассказываем о самых распространенных ошибках, которые совершают медиа при проектировании интерфейсов и как нужно делать правильно.

Данный пост открывает цикл статей о разработке аналитической системы мониторинга действий пользователей. В первой статье мы расскажем о том как собирать необходимые данные с мобильных приложений под андроид и айос.

package Birdy::Stat::Stalin;
#
# Это Сталин, он всё про всех знает
# Кто и что делает, кто и с кем спит
#
# ########################################################
# ########################################################
#
#                 !#########       #
#               !########!          ##!
#            !########!               ###
#         !##########                  ####
#       ######### #####                ######
#        !###!      !####!              ######
#          !           #####            ######!
#                        !####!         #######
#                           #####       #######
#                             !####!   #######!
#                                ####!########
#             ##                   ##########
#           ,######!          !#############
#         ,#### ########################!####!
#       ,####'     ##################!'    #####
#     ,####'            #######              !####!
#    ####'                                      #####
#    ~##                                          ##~
#
# ########################################################
# ########################################################

Нас постоянно спрашивают, почему мы используем библиотеку AQuery в своих проектах. В конце концов нам надоело отвечать и мы решили показать, на что способна AQuery в бою.

Но писать какой-то странный псевдокод в духе hello world скучно и неинтересно и поэтому мы решили сделать какое-нибудь небольшое, но полезное приложение. Недавно от Хабра отделился проект Мегамозг и в комментариях к новости высказывали предложение объединить RSS поток со всех ресурсов. Этим мы и займемся.

В конце получится такой прототип приложения IT News (rss с хабра, гиктаймс, мегамозга и с силиконруса/роем упорядоченные по дате):



Ссылки для торопыжек:
github: github.com/recoilme/itnews
google play: play.google.com/store/apps/details?id=org.freemp.itnews

Однажды мы, в Surfingbird, нашли странную ошибку, из-за которой приложение стабильно крэшилось. Позже оказалось, что почти любое приложение можно довольно просто скрэшить (даже приложения, написанные самой Apple). О том, что же это за ошибка и как её обойти, мы расскажем в статье.

Настало время подводить итоги года, и мы в Surfingbird – решили не выбиваться из тренда.

Все пользователи разные, и мы, как никто другой, об этом знаем. Но всегда можно тыкнуть пальцем в небо и сравнить какую-нибудь фигню с другой фигней, и иногда даже получается забавно.

Итак, мы решили сравнить то, что волновало нас в этом году, а наш дизайнер даже нарисовал инфографику. На диаграмме распределены темы по убыванию популярности:

Почти любое современное приложение не обходится без загрузки картинок из сети и мы, Surfingbird, не исключение. Однако, нельзя просто загружать картинки последовательно, потому что, если пользователь перемотает пару экранов, ему придётся ждать пока загрузятся предыдущие изображения, которые уже и не нужны.
Поэтому, для увеличения отзывчивости приложения и снижения времени ожидания пользователя, мы применили несколько приёмов, о которых и хотим сейчас рассказать.

Сразу, наверное, стоит предупредить, что мы сделали плавающую кнопку немножко по-своему и собственно до релиза библиотеки, реализующей материальный дизайн как таковой. Но обо всем по порядку.

В нашей концепции (приложений, сайта surfingbird.ru) активно используется такое понятие как «сёрф». Сервис генерирует для пользователя набор релевантных его интересам статей и переход к следующей, рекомендуемой статье мы называем «сёрфом». После очередного редизайна мы кнопку сёрф потеряли (раньше она была сверху, в акшенбаре, и до неё было не очень удобно тянуться), чем пользователи были очень возмущены. После просмотра ролика с превью материального дизайна мы загорелись идеей реализовать нечто подобное в приложении.

С одной стороны, нам очень понравилась сама концепция крупной кнопки — на которую хочется нажать, с другой — нас сильно смущало то, что кнопка заслоняет контент и как бы отвлекает, что ли во время чтения. Тогда наш дизайнер предложил научить её «плавать».

В Surfingbird мы используем пуш-уведомления, чтобы сообщать нашим пользователям срочные новости и просто информировать их об интересных материалах за день. Уже в первые недели тестов пуши показали свою огромную эффективность в плане увлечения ретеншена. Этому есть логичное объяснение – телефон у пользователя всегда с собой, в метро, в туалете, на совещаниях и т. д. Когда юзеру приходит пуш, все его внимание концентрируется на этом уведомлении.

Мы реализовали отправку пуш-уведомлений с бекенда на языке программирования Perl. Однако, когда мы только начали внедрять пуши, то столкнулись с некоторыми трудностями. О трудностях и их преодолении мы и хотим рассказать в этом посте.

Настало время переходить на Lollipop, друзья. Как бы смешно это не звучало.



Буквально вчера мы в Surfingbird обновили дизайн приложения и сегодня, по свежим следам, хотелось бы поделиться впечатлениями от перехода на material design.

Доброго дня! Мы, мобильные разработчики компании surfingbird, решили попробовать написать небольшой цикл статей о том с какими трудностями мы сталкиваемся в процессе разработки мобильных приложений (android, ios), и как мы их решаем. Первый пост мы решили посвятить проблеме webview. Сразу оговорюсь, что решили мы эту проблему несколько кардинально… Для того чтобы было более понятно, придется рассказать пару слов о собственно том, чем мы занимаемся. Мы агрегируем контент из различных источников (парсим оригинальные статьи), выделяем значимую часть (контент) и на основе оценок пользователя и всяких сложных алгоритмов рекомендуем их конечному пользователю ну и конечно просто отображаем в более удобном виде.

В мобильных приложениях мы стремимся не только очистить страницы от элементов верстки и назойливых всплывающих окон, но и оптимизировать контент для потребления на мобильных устройствах.

Но при использовании webview для отображения контента мы столкнулись с рядом сложностей. Этот компонент тяжело поддается кастомизации и довольно тяжел и даже, я бы сказал, глючен. Настал день, когда мы поняли, что не хотим больше видеть webview вообще. Но избавиться от него, учитывая то, что контент у нас отдается в html — оказалось не так-то просто. Поэтому мы решили превратить html в нативные компоненты.

Продолжаем разговор. В прошлый раз мы сделали первый шаг на переходе от наивного байесовского классификатора к LDA: убрали из наивного байеса необходимость в разметке тренировочного набора, сделав из него модель кластеризации, которую можно обучать ЕМ-алгоритмом. Сегодня у меня уже не осталось отговорок – придётся рассказывать про саму модель LDA и показывать, как она работает. Когда-то мы уже говорили об LDA в этом блоге, но тогда рассказ был совсем короткий и без весьма существенных подробностей. Надеюсь, что в этот раз удастся рассказать больше и понятнее.

Продолжаем разговор. Прошлая статья была переходной от предыдущего цикла о графических моделях вообще (часть 1, часть 2, часть 3, часть 4) к новому мини-циклу о тематическом моделировании: мы поговорили о сэмплировании как методе вывода в графических моделях. А теперь мы начинаем путь к модели латентного размещения Дирихле (latent Dirichlet allocation) и к тому, как все эти чудесные алгоритмы сэмплирования применяются на практике. Сегодня – часть первая, в которой мы поймём, куда есть смысл обобщать наивный байесовский классификатор, и заодно немного поговорим о кластеризации.

И снова здравствуйте! Сегодня я продолжаю серию статей в блоге Surfingbird, посвящённую разным методам рекомендаций, а также иногда и просто разного рода вероятностным моделям. Давным-давно, кажется, в прошлую пятницу летом прошлого года, я написал небольшой цикл о графических вероятностных моделях: первая часть вводила основы графических вероятностных моделей, во второй части было несколько примеров, часть 3 рассказывала об алгоритме передачи сообщений, а в четвёртой части мы кратко поговорили о вариационных приближениях. Цикл заканчивался обещанием поговорить о сэмплировании — ну что ж, не прошло и года. Вообще говоря, в этом мини-цикле я поведу речь более предметно о модели LDA и о том, как она помогает нам делать рекомендации текстового контента. Но сегодня начну с того, что выполню давнее обещание и расскажу о сэмплировании в вероятностных моделях — одном из основных методов приближённого вывода.

Все лето мы трудились над Surfingbird 2.0. Sufingbird это рекомендательная система контента, которая ориентируется на ваши интересы, оценки и действия



Во-первых, приложение стало в несколько раз быстрее и стабильнее

Во-вторых, мы постепенно стали адаптировать контент под приложение. Только текст и фото без флешовых банеров и т.д.

В-третьих, переработан весь дизайн приложения. Мы старались прийти к полному flat дизайну, отрезая все лишнее.

В-четвертых, все фичи, которые есть у нас на WEB, доступны в новом приложении. В том числе работа с коллекциями.

В разработке мобильных приложений мы все еще новички и нам очень хочется знать мнение пользователей Хабра.

Для тестирования мы используем hockeyapp.net
Чтобы мы могли выслать вам приглашение, напишите свой email в комментариях или просто отправьте письмо на appledev@surfingbird.ru

В четвёртой серии цикла о графических вероятностных моделях (часть 1, часть 2, часть 3) мы продолжим разговор о том, как справляться со сложными фактор-графами. В прошлый раз мы изучили алгоритм передачи сообщений, который, правда, работает только в тех случаях, когда фактор-граф представляет собой дерево, и в каждом узле можно без проблем пересчитать распределения грубой силой. Что делать в по-настоящему интересных случаях, когда в графе есть большие содержательные циклы, мы начнём обсуждать сегодня – поговорим о паре относительно простых методов и обсудим очень мощный, но непростой в использовании инструмент – вариационные приближения.

После большого перерыва продолжаем цикл о графических вероятностных моделях (часть 1, часть 2). Сегодня мы наконец-то от постановок задач перейдём к алгоритмам; поговорим мы о самом простом, но часто полезном алгоритме вывода на фактор-графах – алгоритме передачи сообщений. Или, как его ещё можно назвать, алгоритме правильной расстановки скобок.


by sergey-lesiuk

Сегодня – вторая серия цикла, начатого в прошлый раз; тогда мы поговорили о направленных графических вероятностных моделях, нарисовали главные картинки этой науки и обсудили, каким зависимостям и независимостям они соответствуют. Сегодня – ряд иллюстраций к материалу прошлого раза; мы обсудим несколько важных и интересных моделей, нарисуем соответствующие им картинки и увидим, каким факторизациям совместного распределения всех переменных они соответствуют.

В этом блоге мы уже много о чём поговорили: были краткие описания основных рекомендательных алгоритмов (постановка задачи, user-based и item-based, SVD: 1, 2, 3, 4), о нескольких моделях для работы с контентом (наивный Байес, LDA, обзор методов анализа текстов), был цикл статей о холодном старте (постановка задачи, текстмайнинг, теги), была мини-серия о многоруких бандитах (часть 1, часть 2).

Чтобы двигаться дальше и поместить эти и многие другие методы в общий контекст, нам нужно выработать некую общую базу, научиться языку, на котором разговаривают современные методы обработки данных, – языку графических вероятностных моделей. Сегодня – первая часть этого рассказа, самая простая, с картинками и пояснениями.

Обычно подобные статьи очень общие и сводятся к советам из серии «Делайте хороший продукт, зарядку по утрам и слушайтесь маму — и тогда ваши пользователи будут возвращаться к вам снова и снова». Я же, хоть и не обещаю серебряную пулю в плане повышения retention rate, но зато расскажу, что конкретно мы для этого делаем в Surfingbird.

В нашем случае с нами остается треть юзеров, причем навсегда. Они пользуются Surfingbird каждый месяц.

Сегодня я расскажу о том, как можно использовать данные о пользователях из социальных сетей для рекомендаций веб-страниц на холодном старте. Все приведенные в статье результаты носят чисто экспериментальный характер и в настоящий момент не реализованы в продакшене. Здесь, как и в прошлой статье, будут использоваться элементы текстмайнига для анализа текстового контента веб-страниц.

Сначала немного статистики для того, чтобы показать важность настоящего исследования. Около 50% пользователей нашей системы регистрируются с привязкой аккаунтов социальных сетей vkontakte (VK) и facebook (FB). Причем из зарегистрированных через социальные сети 71% приходится на VK и 29% на FB.

API FB и API VK позволяют извлекать некоторые данные об интересах и предпочтениях пользователя. Но не все так просто, как может показаться. Для получения данных пользователя нужно получить особые права, согласие на которые дает сам пользователь при регистрации в системе. Здесь возникает тонкий момент. С одной стороны, мы ходим вытянуть как можно больше информации о пользователе. С другой стороны, просить слишком много прав — наглость, которая может отпугнуть пользователя. Нужно найти компромисс — тонкое равновесие между полезностью получаемых данных для улучшения рекомендаций и «суммой» кредита доверия от пользователя, который соглашается, чтобы мы залезли в его персональные данные.