недействительный запрос обратитесь к разработчику приложения
Что делать разработчику, если пользователь просит вернуть деньги?
Сегодня мы поговорим о том, как отвечать пользователю вашего приложения или игры, если он хочет вернуть деньги. Спойлер – вы не всегда обязаны делать это по первому же требованию. Дайте посмотрим, в каких случаях средства все же придется вернуть, а в каких можно попытаться сохранить транзакцию.
Что делать, если пользователь требует возврата денег сразу после списания с карты?
Если с момента покупки прошло менее 48 часов, то вы можете смело отправлять пользователя к самим маркетплейсам приложений. Именно они снимают деньги за покупку, и, скорее всего, еще даже не переслали их на ваш счет. Такой механизм возврата предусмотрен правилами Google Play.
В свою очередь, Apple App Store в своих Положениях и условиях продажи товара указывает, что приложения и подписки вообще не относятся к товарам, подлежащим возврату. Кроме случаев дефекта или несоответствия. Однако попробовать запросить возврат средств через специальную форму пользователь все-таки может.
А если пользователь просит вернуть деньги, когда прошло уже больше 48 часов?
После двух суток с момента покупки Google Play советует обращаться напрямую к разработчикам приложения. Пользователь должен описать свою проблему, а также желаемое решение – устранение неполадок или возврат средств.
Вы же, со своей стороны, анализируете запрос, разбираетесь в деталях операции (или не разбираетесь) и даете ответ в течение трех рабочих дней. Правила Google описывают сроки ответа и то, что реакция должна быть вежливой и профессиональной. Однако напрямую они не предусматривают ответственности за отсутствие ответа в срок.
В комментарии запроса вы можете дать пользователю ссылку на свою EULA (о том, что это такое и как ее написать, можно почитать здесь) или Правила пользования. В них должна быть описана ваша политика возврата денег. В этих документах можно прописать положение о том, что все сделки являются окончательными – создавая аккаунт в приложении или скачивая его себе на устройство, пользователь соглашается с тем, что продукт не подлежит возврату.
Пользователь просит вернуть деньги за его покупки в приложении после блокировки аккаунта
Не обязательно. В своем Пользовательском соглашении (Terms of Use) вам нужно прописать положение о том, что приобретая виртуальные товары, пользователь соглашается с тем, что он теряет свое право на отказ от договора купли-продажи. В таком случае возвращать деньги вы не должны. Главное убедиться, что пользователь принял соглашение.
Например, такое положение предусмотрено в Правилах пользования услуг компании Wargaming, всем известной по World of Tanks, World of Warships Blitz и других:
В тех же Terms of Use стоит прописать свое право заблокировать аккаунт пользователя в случае нарушения правил – без возможности возврата денег. Тогда в ответе на запрос пользователя вы сможете сослаться на этот пункт.
Что делать, если пользователь требует вернуть ему деньги, потому что покупку совершил по ошибке его «дедушка», «ребенок», «друг», «кот»?
В такой ситуации вы тоже не обязаны возвращать деньги. Но всегда стоит смотреть по ситуации – возможно стоит пойти навстречу и заработать себе плюсик к карме.
Сами магазины приложений недвусмысленно намекают пользователю, что ответственность за совершенные покупки лежит на владельце аккаунта:
Поэтому в ответе на такой запрос вы можете вновь отправить пользователя к вашим локальным правилам. Где, конечно, должен быть пункт в духе: «в случае ошибочной покупки продукта вашим родственником / иным лицом с вашего аккаунта, деньги не возвращаются». А также повторить совет Apple о настройках экранного времени и функции родительского контроля.
Если я не верну деньги пользователю, сможет ли он пойти в суд и привлечь меня к ответственности?
На этот вопрос нет однозначного ответа. До сих пор ведутся споры, является ли приложение «товаром или услугой» и распространяются ли гарантии потребительских законов на пользователей. И практика применения таких законов судами очень скудная.
Но на что суды могут обратить внимание, так это на вашу EULA. Если вы четко пропишете все правила покупки, оплаты и возврата своего продукта, то есть вероятность, что суд встанет на вашу сторону. Как например в деле известной своей неоднозначной Facebook-рекламой игры «Великий султан».
Игрок просил вернуть деньги за встроенные покупки, ведь он «не знал, что их списывают». Однако суд подтвердил, что скачивая игру, пользователь соглашается с условиями использования – а значит он должен был знать о ценах на покупки и был согласен со списаниями.
Как видите, чтобы разработчик чувствовал себя спокойно, нужно грамотно составить пользовательское соглашение. Оно должно четко описывать механизмы покупки, возврата средств и ответственности сторон.
А дальше вы уже можете действовать исходя из каждой конкретной ситуации и своих имиджевых целей. Возможно, ситуация просто вынуждает пойти на возвраты, несмотря на денежные потери – как недавняя история с Cyberpunk 2077 в PlayStation Store. Или может вам лучше сохранить лояльность пользователя, чем его покупку.
Потому хорошие правила пользования дают вам простор для маневров.
Устранение проблем с упаковкой и развертыванием приложений для Windows, а также с обращением к ним
используйте эти рекомендации для устранения неполадок, возникающих при упаковке, развертывании или запросе пакета приложения Windows (. msix/. appx) в качестве разработчика.
Эта статья предназначена для разработчиков. если вы не являетесь разработчиком и ищете справку по Windows ошибке установки приложения, см. статью поддержка Windows.
Получение диагностических сведений
При сбое API возвращается код ошибки, описывающий проблему. Если код ошибки не содержит достаточно сведений, вы найдете дополнительные диагностические сведения в подробных журналах событий.
Чтобы получить доступ к журналам событий упаковки и развертывания с помощью Просмотр событий, выполните следующие действия.
Выполните одно из следующих действий.
на левой странице разверните узлы Просмотр событий (локальные) > журналы приложений и служб > Microsoft > Windows.
Проверьте наличие доступных журналов в следующих категориях:
Начните с просмотра журналов в разделе AppXDeployment-Server. Если ошибка вызвана 0x80073CF0 или ERROR_INSTALL_OPEN_PACKAGE_FAILED, в журналах AppxpackagingOM могут присутствовать дополнительные сведения.
Вы также можете использовать команду Get-аппкслог в PowerShell, чтобы получить первые несколько зарегистрированных событий. В следующем примере отображаются журналы, связанные с последней операцией развертывания.
В следующем примере отображаются журналы, связанные с последней операцией развертывания в интерактивной таблице в отдельном окне.
Коды распространенных ошибок
В этой таблице перечислены некоторые из наиболее распространенных кодов ошибок. Если вам нужна дополнительная помощь по одной из этих ошибок или если вы столкнулись с кодом ошибки, отсутствующим в этом списке, см. раздел Дополнительные параметры справки.
Приложения не запускаются, и их имена недоступны
на компьютере, на котором работает Windows 10 или более поздней версии, нельзя запускать некоторые приложения, и имена приложений отображаются серым цветом.
При попытке открыть приложение, выбрав затененное имя, может появиться одно из следующих сообщений об ошибке:
кроме того, следующие записи событий регистрируются в журнале «Microsoft-Windows-твинуи/эксплуатация» в разделе applications and сервицес\микрософт\ Windows \аппс:
Как исправить ошибку «Требуется подтверждение оплаты» при загрузке приложений из App Store
✏️ Нам пишут:
Не могу скачивать приложения из App Store, появляется ошибка: Требуется подтверждение. Для просмотра сведений об оплате нажмите «Продолжить» и войдите в систему. Что делать?
Если при попытке скачивания приложений на iPhone отображается подобная ошибка, скорее всего, у вас имеется задолженность в магазине Apple или на выбранном способе оплаты не хватает средств для продления подписки.
Вот, что нужно делать в таком случае:
1. Перейдите в Настройки – Учетная запись Apple ID – iTunes Store и App Store и нажмите на свою учетную запись.
2. Выберите пункт Посмотреть Apple ID и авторизуйтесь при помощи Touch ID или Face ID.
3. Перейдите в раздел Подписки и посмотрите дату продления существующих подписок. Если недавно требовалось продлить подписку, а средств на счету не хватило, возможно появление указанной ошибки.
4. Вернитесь в предыдущее меню и перейдите в раздел История покупок. Здесь будут отображаться последние скачанные программы, купленные приложения и оплата подписок.
По истории платежей тоже можно найти последние неоплаченные покупки, суммы которых могут превышать остаток баланса. Так поймете, сколько вы должны магазину Apple и на какую сумму пополнять счет.
Если после проделанных манипуляций ошибка не пропадет, следует обратиться в службу поддержки Apple.
Requesting & Revoking Permissions
Each type of login flow has its own method of requesting permissions, depending on your platform and how you choose to integrate Facebook Login:
Mobile Apps
Please note that many of the APIs listed above can also be used to ask for additional permissions later during an app’s lifetime, not just at initial login.
Optimizing Permissions Requests
As a general rule, the more permissions an app requests, the less likely it is that people will use Facebook to log into your app. In fact, our research shows that apps that ask for more than four permissions experience a significant drop off in the number of completed logins.
Guidelines
Here are a few guidelines to use when asking for permissions, both during and after login:
Only ask for the permissions that are essential to an app.
Ask for permission in the context in which they are required. For example, if your app wants to show places of interest near a person’s location, asking for user_location just prior to displaying that information gives the person a greater understanding of why the permission is being requested.
Separate the request of read and publish permissions. For more details, see below.
Never ask for permissions you think you might need in the future. People will be suspicious and may reject your app.
Tell people ahead of time why you are requesting a permission. Explaining why you need access to something will increase the chance that they are willing to share it.
Publishing Permissions
Apps should separate the request of read and publish permissions. Plan your app around requesting the bare minimum of read permissions at initial login and then any publish permissions when a person actually needs them, for example when they want to create an Open Graph story from within the app. This provides the best user experience and optimizes conversion.
You may receive Developer Alerts if your app requests read and publish permissions back-to-back. To stop receiving these alerts, separate your requests or follow the guidelines below for exceptional cases.
In the rare case your app requires publishing permissions up front (for example, an app that does nothing but publish a person’s mood to Facebook) only request the bare minimum read permissions at initial login. After the person logs in, show the person a screen explaining why your app needs publishing permissions and let the person opt-in to the publishing permission request by clicking a button. This will provide them with more context and improve your conversion.
Checking Current Permissions
Facebook offers people full control over the permissions they grant to an app. That control extends beyond the point at which they see the login dialog. They can choose not to grant certain permissions during the login process. They can also revoke permissions in their Facebook privacy settings at any time. Apps should check for the validity of permissions before attempting to perform an API call where they are required. For example, checking that email is still granted before sending a message.
For web apps, we provide a graph API endpoint to retrieve a list of granted permissions:
The call must be made with either a user access token or your app access token. The call will return a JSON string containing the permission names which have been granted to the app and their status:
We also provide methods in the iOS and Android SDKs that provide platform-friendly representations of the permissions your app has been granted.
Handling Missing Permissions
When an app requests permissions, people may completely deny those permissions, not fully grant those permissions, or change them later. In order to provide a great experience, apps should be built to handle these situations.
First, apps should be able to handle any permissions that were requested but not granted:
Once an app has detected that someone has denied some or all permissions, it may pass them back through the login flow once and request any required permissions. However, this is a poor experience and should be avoided if possible. If someone is actively choosing not to grant a specific permission to an app they are unlikely to change their mind, even in the face of continued prompting. Instead, do the following:
If a person declines the login dialog have a clear and upfront explanation about why you are requesting each permission. Then let them click or tap to opt back in to the permission request dialog. Do not immediately redirect them into a permission request dialog without an explanation.
If someone has declined a permission for your app, the login dialog won’t let your app re-request the permission unless you pass auth_type=rerequest along with your request.
For cases where someone has granted some permissions but not others, only prompt for missing permissions at the point at which they are needed. For example, if your app sends order confirmations to users’ email, only request email when they make an order.
Unless the permissions you are requesting in the login dialog are critical to the functionality of your app and a feature doesn’t work without them, let people continue using your app without the permissions.
You may receive Developer Alerts if your app repeatedly directs users to permissions dialogs after they deny permissions. To stop receiving these alerts, follow these guidelines.
Revoking Permissions
Apps can let people revoke permissions that were previously granted. For example, your app could have a settings page that lets someone disable sending them email messages. That settings page could also revoke the email permission at the same time.
You can revoke a specific permission by making a call to a Graph API endpoint:
Revoking Login
You can also let people completely de-authorize an app, or revoke login, by making a call to this Graph API endpoint:
Обработка ошибок, контент, аналитика: что проверить перед запуском мобильного приложения Статьи редакции
Список от руководителя проектов компании-разработчика MobileUp Олега Широкова.
Несколько месяцев вы с разработчиками трудились над созданием приложения. Настало время его выпускать. Все фичи готовы и работают, как задумано.
Но всё же есть вероятность, что в процессе был упущен какой-нибудь важный момент. Поэтому мы собрали список распространённых ошибок, которые нужно обязательно проверить перед релизом, даже если вас убеждают, что всё нормально.
Материал поможет продакт-менеджерам и собственникам бизнеса на клиентской стороне убедиться в том, что их приложение действительно готово к релизу и не нуждается в срочных доработках.
Нужно проверить, как приложение ведёт себя в проблемных ситуациях. Детально это изучают тестировщики, поэтому здесь речь идет о быстром smoke-тесте самых популярных кейсов.
Если приложение использует геолокацию, то нужно проверить, как оно ведёт себя в типичных случаях.
Первая ситуация: пользователь запретил приложению доступ к геолокации
Как должно быть: показать пользователю сообщение и предложить перейти в настройки, чтобы разрешить доступ.
Как проверить: в настройках запретить приложению доступ к геоданным и запустить приложение.
Вторая ситуация: приложению не удаётся быстро определить координаты пользователя. Например, если он находится в помещении или выключил Wi-Fi и мобильный интернет.
Как должно быть: показать последнее определённое местоположение пользователя, а если его нет — показать какую-то точку по умолчанию или заглушку, но не карту в море.
Как проверять: включить авиарежим и запустить приложение.
Первая ситуация: пользователь совершает действие, для которого нужен доступ к интернету. Например, нажимает на кнопку «Загрузить». А интернета в этот момент нет.
Как должно быть: пользователь остаётся на том же экране и видит сообщение об отсутствии интернета на понятном человеческом языке.
Как проверить: запустить приложение, выключить интернет, нажать на какую-нибудь кнопку действия.
Вторая ситуация: пользователь хочет перейти в другой раздел приложения, например, из бокового меню, а доступа к интернету нет.
Как должно быть: приложение загрузит раздел в том состоянии, в котором пользователь покинул в последний раз. Пользователь увидит сообщение об отсутствии интернета на понятном человеческом языке.
Как проверить: запустить приложение, зайти в один из разделов, потом перейти в другой, отключить интернет, вернуться в предыдущий раздел.
Третья ситуация: интернет есть, но нестабильный — и он пропал в процессе загрузки экрана.
Как должно быть: пользователь увидит не пустой экран, а экран-заглушку с грустной иконкой и сообщением об отсутствии интернета. Если часть данных уже успела загрузиться, приложение оставит их на экране и покажет сообщение о том, что есть проблемы с интернетом.
Как проверить: запустить приложение, зайти в один из разделов, потом перейти в другой раздел, для которого нужно загрузить много данных с сервера, и в процессе загрузки отключить интернет.
Четвёртая ситуация: при открытии экрана не было интернета, он появился уже после.
Обработка такой ситуации нужна не в каждом приложении и не на каждом экране. Но она очень актуальна для чатов, соцсетей и приложений, работающих с картой.
Как должно быть: приложение периодически проверяет, не появился ли интернет снова. Если появился — загружает нужные данные автоматически без дополнительных действий со стороны пользователя.
Как проверить: запустить приложение, включить авиарежим, выключить авиарежим.
Сервер может возвращать различные виды ошибок. При этом пользователь не должен видеть непонятные сообщения вроде «401 Token is invalid» или неопределенное «Internal server error». Нужно объяснить ему, что делать: попробовать совершить действие ещё раз через некоторое время или обратиться в службу технической поддержки.
Логика и сценарий проверки здесь такие же, как и при проблемах с интернетом. Только вместо отключения интернета нужно попросить серверного разработчика отдавать приложению различные ошибки.
Во всех случаях должно отображаться сообщение на понятном языке или экран-заглушка.
Любой грамотный дизайнер или разработчик скажет вам, что текст на экране так же важен, как удобный интерфейс и отсутствие багов. Пользователи часто не могут разобраться с непонятными пояснениями и названиями кнопок. А конкурентов и многочисленных «диванных» экспертов знатно повеселят найденные орфографические ошибки.
Поэтому обязательно нужно заглянуть на каждый экран приложения и проверить тексты на внятность и орфографические ошибки. Для ускорения работы можно попросить разработчиков сделать скриншоты всех экранов и состояний через специальный сервис. Например, Fastlane Snapshot.
В продуманных приложениях названия кнопок соответствуют тому, что произойдёт при их нажатии, и побуждают к действию. Например: «Выбрать» и «Подтвердить» вместо «ОК», «Отказаться» вместо «Отмена», «Найти мастера» вместо «Поиск мастеров».
В разделе с проблемами мы говорили, что сообщения об ошибках должны быть написаны на понятном каждому человеку языке. На самом деле, это относится ко всем текстам в приложении.
Когда пользователь совершает критичные действия, которые нельзя вернуть назад или которые могут доставить ему неудобства, нужно обязательно показывать диалоги-подтверждения. Примеры таких действий: выход из учётной записи, удаление контента, отмена заказа и так далее.
Когда пользователь только установил приложение, в некоторых разделах у него будет пусто, например, в списке заказов. Чтобы эти разделы не были пустыми и грустными, в них размещают специальные заглушки с картинкой и пояснением, как заполнить этот раздел.
В продуманном приложении помимо текста будет кнопка. Например, «Создать первый заказ».
В продуманных приложениях на видном месте (например, в боковом меню или в профиле) есть контакты технической поддержки. Это позволяет уменьшить количество гневных отзывов в App Store и Google Play.
Перед релизом в приложения обычно интегрируют один или несколько сервисов по сбору аналитики: Google Analytics, Mixpanel, Fabric.io, Flurry, Appsee. Собранные данные можно удобно просматривать в веб-интерфейсе.
Если это ваше первое мобильное приложение, то вы, скорее всего, не будете детально знать, какие действия нужно отслеживать. Но есть минимальный набор, который точно нужно настроить.
Чтобы отслеживать, как часто приложение «падает» и у какого процента пользователей, настраивают сбор крэшей. Кроме того, они помогают разработчикам быстрее разобраться с причиной падения.
Часть этой информации можно посмотреть в iTunesConnect или Google Developer Console и без интеграции отдельного сервиса. Полный набор: количество установок, количество активных пользователей, среднее время, проводимое в приложении и прочее, — доступен только в специализированных сервисах аналитики.
Эта информация даст понять, востребовано ли ваше приложение и помог ли бюджет на продвижение.
Так вы сможете узнать, в каких разделах приложения пользователи проводят больше всего времени. Например, если у вас есть важный раздел с акциями, но пользователи туда не заходят, то, возможно, интерфейс приложения нужно доработать.
Если в приложении пользователи что-то заказывают или покупают, смотреть количество этих действий и считать конверсию удобно в аналитике. Для этого нужно настроить специальные «кастомные события». В приложении «Туту ЖД» список таких событий занимает четыре полных листа А4.
Если у вас не такой масштабный проект, то вам будет достаточно одного-трёх событий. Например, «Заказ оплачен» или «Лайк новости».
На ранних этапах разработчик обычно настраивает взаимодействие с внешними сервисами через тестовые аккаунты. Например:
К моменту релиза приложения все эти сервисы должны быть переведены на аккаунты заказчика. Это может показаться очевидным, но мы не раз сталкивались с ситуациями, когда это не было сделано. Также после перевода всех сервисов на аккаунты заказчика нужно проверить, что они работают.
Мне кажется всю статью нужно заменить на один совет:
Проверьте, что вы наняли квалифицированного специалиста по тестированию
В iOS-приложении Profi.ru кнопка «Заказать» в «Избранном» не подходит по смыслу. При нажатии на неё открывается форма для отправки сообщения специалистам. Заказ при этом не оформляется.
Так что мы вас понимаем, но пример не самый удачный. 😉
Правильные решения находятся в точке баланса метрик и создания верных ожиданий у пользователя.