В метрике не работает вебвизор: Не работает вебвизор в Яндекс.Метрике | Дропшиппинг

Содержание

7 советов по эффективному использованию Яндекс.Метрики

Несколько рекомендаций, которые позволят вам стать более уверенными пользователями Яндекс.Метрики

1. Запускайте ретаргетинг по сегментам, а не по целям

Ретаргетинг – это возможность повторной коммуникации на сайте с пользователями, которые уже посетили его ранее. «Яндекс.Метрика» позволяет настроить ретаргетинг двумя способами: по целям и сегментам.

Несмотря на то, что цели — это более понятный инструмент (настройка действий, которые пользователь должен совершить на сайте), такой подход накладывает некоторые ограничения на работу ретаргетинга.

По ссылке вы можете посмотреть популярные кейсы использования ретаргетинга.

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

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

Кроме того, сегменты работают на исторических данных, что очень удобно для тех, кто забыл вовремя настроить цели.

2. Используйте модели атрибуции

Что такое атрибуция? Атрибуция — это когда мы присваиваем источнику трафика какое-то конверсионное действие пользователя либо привязываем (атрибуцируем) его к определенному источнику трафика. Первый случай можно объяснить достаточно просто: допустим, пользователь несколько раз пришел на сайт из разных источников трафика и в конце концов совершил покупку. Нужно понять: кто привел этого клиента? Последний источник трафика — тот, после которого была совершена покупка, или первый источник трафика, благодаря которому произошло знакомство с сайтом?

В случае с привязыванием человека к источнику трафика атрибуция работает всегда: вне зависимости, есть конверсия или нет.

Можно отследить, какой источник трафика привел пользователя в первый и последний раз, даже если он не сделал конверсию.

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

3. Используйте Вебвизор эффективно

С помощью Вебвизора вы можете отсмотреть до 150 тысяч записей визитов деперсонифицированных пользователей на ваш сайт и определить, какие проблемы его функционирования необходимо решить. Естественно, просмотреть все записи не получится, хотя мы часто наталкиваемся на публикации в стиле: «Сегодня всю ночь не спал, смотрел Вебвизор», или: «Я смотрю Вебвизор вместо сериалов».

Как использовать Вебвизор для решения проблем с дизайном сайта: кейс интернет-магазина мебели.

Такое большое количество записей предоставляется пользователям для сегментирования аудитории по моделям поведения на сайте. Например, у вас снизились конверсии и упали продажи. Почему? Возможно, потому что что-то не так с оформлением заявки. Вы объединяете в сегмент посетителей сайта, которые заполняют заявки, но не доходят до страницы «спасибо», а затем смотрите, что происходило в течение их сессии. Таким образом, этот инструмент помогает отследить проблемы во взаимодействии посетителей с сайтом, которые могут остаться незамеченными в других отчетах Метрики.

4. Настройте передачу e-commerce данных

Очень многие люди думают, что e-commerce модуль создан исключительно для классических интернет-магазинов, которые продают электронику, одежду, игрушки и т. д. Но на самом деле e-commerce позволяет обогатить данные Метрики и получить больше агрегированных данных о пользовательском поведении на сайте. Понять, какие категории продуктов наиболее популярны и чем заканчивается пользовательская сессия на сайте.
Где можно использовать e-commerce модуль кроме классических интернет-магазинов?

Любые другие сайты по продаже товаров и услуг

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

Контентные сайты (паблишеры)

Медиа могут использовать e-commerce модуль, чтобы передавать подробную информацию о каждой публикации. Здесь вместо характеристик товара можно отправлять имя автора, дату публикации, теги материала и рубрики, к которым он относится. Это позволит выявлять авторов самых читаемых материалов, или, например, рубрики с максимальным количеством просмотров. Набор передаваемых данных о статье может быть любым, так что медиа могут построить собственные редакционные метрики.

Как настроить передачу e-commerce данных: инструкция для разработчика

5. Свяжите колл-трекер с Метрикой

Зачастую, когда пользователь заходит на веб-страницу компании, он может не только отправить заявку, но и позвонить. «Колл-трекер» — это сервис, который позволяет отслеживать звонки, приходящие на сайт. Статус звонка также полезно исследовать как одно из целевых действий, так как во время телефонных разговоров не только уточняются детали, но и оформляются заказы, особенно это характерно для региональных сайтов и клиентов. К Метрике подключены все известные колл-трекеры в России и СНГ, так что если вы уже пользуетесь колл-трекинговой системой, достаточно будет просто указать в ней номер счётчика Метрики. Данные будут автоматически передаваться и связываться с остальной историей посетителя, что позволит получить более подробную информацию о звонках: были ли они целевыми, повторными или первичными, произошла ли продажа, а также понять, насколько качественно работают колл-центр и источники трафика.

Список колл-трекеров, интегрированных с Метрикой, доступен по ссылке.

6. Настройте передачу офлайн-конверсий

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

7. Используйте параметры визитов для более глубокого понимания посетителей

В Метрике хранится много информации о посетителе.

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

Как найти проблемы на лэндинге — Блог Carrot Quest

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

В конце мая Carrot Quest совместно с ФРИИ и Ильей Красинским провели необычный workshop, основной целью которого было улучшение юнит-экономики 5 стартапов. Илья Красинский был главным вдохновителем и спикером мероприятия (Илья — эксперт и тренер Акселератора ФРИИ, основатель AppCraft, ментор, коуч и предприниматель в Magic Ink). Мероприятие заключалось в том, чтобы проанализировать текущие показатели лэндингов стартапов и подтянуть их проблемные места. Ключевым элементов при анализе как раз был Вебвизор, о котором подробно и поговорим.

Существуют два варианта анализа работы лэндинга: «качественый» и «количественный».

Количественный — это сбор метрик: количество пользователей из канала и конверсия по разным действиям. Далеко не всегда можно собрать достаточное количество данных, чтобы на их основе делать выводы. Особенно, если вы начинающий проект.

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

Вебвизор — это главная фишка Яндекс Метрики, с помощью которой можно просматривать как вел себя пользователь на вашем сайте, словно вы «смотрите на экран его глазами».

Вы в точности увидите:

движение мыши;
клики;
прокрутка страниц;
нажатие на клавиши и заполнение форм;
выделение и копирование текста;
разрешение экрана посетителя.

Основная особенность этого инструмента в том, что вы начинаете понимать, как посетители «читают» лэндинг, на каких моментах «притормаживают», что пропускают, не убегают ли раньше времени на другие страницы.

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

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

Как отбирать сегменты посетителей для анализа

Определите сегменты пользователей (группы), которые будете анализировать. Сегменты отбираются для того, что найти в их поведении определенные взаимосвязи (например, какое действие совершают те, кто в итоге покупает, в отличие от тех, кто не покупает). Так как аудитория различается , то анализ по всем посетителям не даст таких результатов, как по отдельному сегменту. Для этого в Вебвизоре можно фильтровать «испытуемых».

Чаще всего пары условий будет достаточно:

1. Период времени.

С этим знакомы все, единственный нюанс — Вебвизор хранит историю действий только за последние 14 дней. Очень мало, но может пригодиться.

2. Источники трафика.

Аудитория из разных каналов отличается (разная осведомленность, мотивы, отсюда и поведение иное).Вы выбираете любой канал привлечения аудитории и анализируете аудиторию из него. Учитывайте особенности аудитории по каналам. Например, если пользователи пришли с описательной статьи в журнале о вас, то они уже знакомы с вашим предложением и их поведение будет серьезно отличаться от «новичков».

3. UTM-Метки.

Чтобы в каждом канале анализировать любую кампанию, вы создаете utm-метки. Для вас это актуально именно из-за возможности понимать осведомленность аудитории по каждой метке.

Например, если вы занимаетесь контент-маркетингом и публикуете статьи, то вы знаете, что не во всех материалах возможно написать что-то о своей компании (часто вы пишите просто обучающий материал без рекламы, например, как мы в этой статье). Если вы подробно в статье рассказываете о себе, то и аудитория к вам придет достаточно осведомленная, и ее поведение будет отличаться от аудитории, которая придет со статьи без описания о вас.

Сервис от Google поможет вам скомпоновать такие метки.

4. Продолжительность посещения.

Два сценария.

Во-первых, можно определить сегменты пользователей с минимальным временем посещения сайта и попытаться понять, почему они уходят так рано и какие элементы лэндинга их не «цепляют» и не удерживают (не беспокойтесь раньше времени, это могут оказаться и люди не вашей ЦА, а просто те, кто случайно к вам попал).

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

Обратите внимание, что с этим фильтром будут попадаться и те, кто просто «уснул» на сайте (свернул его или перешел на другую вкладку). Они нам не нужны, поэтому дополнительно фильтруйте аудиторию по ее АКИВНОСТИ, так вы отсечете ненужных.

5. Достигшие цели.

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

А вот пример. 90% достигших цели пользователей просматривали внимательно первый блок на главной странице сайта. Это значит, что подробное изучение этого блока играет важную роль, сделайте так, чтобы почти каждый пользователь останавливался в этом месте и увлеченно читал)))

6. Не достигшие цели.

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

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

На что обращать внимание при анализе

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

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

За какими действиями наблюдать:

1. Чтение заголовков.

Заголовки — это лишь верхушка айсберга, но ведь она очень важна. Крупные заголовки читают 70-85% посетителей. Просто посмотрите, как долго «испытуемые» останавливаются на заголовках (например, многие водят по ним мышкой, пример ниже) и какое действие после прочтения делают.

Вот скриншот из Вебвизора при анализе лэндинга сервиса для автоматизации и персонализации маркетинга — Carrot Quest. Обратите внимание, посетитель ведет мышкой по тексту. Понятно, он прочитал основной текст, на подзаголовок обратил уже меньше внимания и пошел дальше.

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

2. Чтение текста под заголовками.

Обычно эти тексты читают всего 5-15%, поэтому не оставляйте в них самую важную информацию. Прикидывайте, сколько времени пользователь сидит на одном блоке сайта, какой текст за это время он сможет прочитать.

2. Как просматривают (прокручивают) сайт.

Чаще всего, когда пользователя ничего не зацепило, он быстро прокручивает сайт до конца, быстро скролит вверх и уходит. Обращайте внимание на такое поведение. Если оно встречается очень часто, пора задуматься о корректировке лендинга.

И наоборот, если пользователь остановился на каком-то блоке лэндинга — это сигнал: возможно, это ценностное предложение его заинтересовало.

3. Как взаимодействуют с формами на сайте.

Пользователи без проблем заполняют формы, нажимают на кнопки и т. д.? Или же есть какие-то сложности? Не все так просто, как может показаться на первый взгляд при проектировании лендинга.

Стоит посмотреть, где у пользователей бывают проблемы с заполнением форм регистрации.

4. Как ваш сайт работает в других браузерах и разрешениях.

Желательно, конечно, это проверять заранее, хотя лишняя проверка не помешает.

5. Быстрый уход с главной страницы.

Об этом мы уже говорили выше, но давайте повторим. Если пользователь еще не знает ценности вашего продукта (например, пришел из канала, где почти не было ни слова о компании), при этом, попадая на главную страницу, сразу с нее «бежит» на другие (например, на страницу с тарифами), возможно, это проблема. Главная страница не вызывает желания у пользователя ее просматривать, а чаще всего ваша основная ценность описана на главной странице. Нет ценности — нет продаж.

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

P.S.

Кстати, Яндекс Вебвизор не показывает, что происходит у вас в админке, ведь он следит за пользователями только на лэндинге. Если у вас SaaS-сервис, и вы хотите проводить такой же анализ поведения пользователей еще и в админке или использовать больше возможностей, то советуем вам приглядеться к похожим на Вебвизор сервисам: inspectlet.com, fullstory.com, mousestats.com, mouseflow.com, www.hotjar.com.

Пишите о своем опыте, делитесь мнениями, спрашивайте.

С удовольствием, команда Carrot Quest

WebView и навигация с помощью кнопки «Назад» в Android

WebView — это компонент Android, который позволяет разработчикам отображать веб-страницу в приложении.

Существуют различные сценарии, в которых может быть полезен WebView. Например, его можно использовать для отображения общей страницы между Интернетом и Android, такой как страница «Условия и конфиденциальность». Его также можно использовать для отображения страницы, тем самым избегая сетевого запроса, а затем анализировать данные для их отображения в макете Android.

Вы можете подумать, что если вы можете отображать веб-страницу в приложении для Android, то вы можете создать собственное приложение для браузера!

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

В этой статье мы расскажем о решениях распространенных проблем, с которыми разработчики Android часто сталкиваются при использовании WebView, например о том, как настроить навигацию с помощью кнопки «Назад» в Android. Весь код в этой статье написан на Kotlin.

Перейти вперед:

Обработка навигации по страницам и перезагрузка страницы при отсутствии содержимого
Обработка навигации с помощью кнопки «Назад»
Анализ посещаемых URL-адресов
Отображение экрана загрузки во время загрузки страницы
Обработка сбоев процесса рендеринга

Обработка навигации по страницам и перезагрузка страницы при отсутствии содержимого

Когда пользователь щелкает ссылку внутри WebView, операционная система Android попытается открыть ее во внешнем приложении, которое может обрабатывать URL-адреса, например в браузере:

Чтобы позволить пользователю перемещаться назад и вперед по истории своей веб-страницы, вам необходимо предоставить WebViewClient для WebView:

 val myWebView: WebView = findViewById(R. id.webview)
myWebView.webViewClient = WebViewClient()

Вместо использования стандартного WebViewClient вы также можете реализовать свой собственный, например:

 myWebView.webViewClient = объект: WebViewClient() {
    …
}

Два наиболее часто переопределяемых поведения WebViewClient , onPageStarted и onPageFinished .

 myWebView.webViewClient = объект: WebViewClient() {
     переопределить удовольствие onPageStarted (представление: WebView?, URL: строка?, иконка: растровое изображение?) {
         super.onPageStarted(вид, URL, значок)
     }
      переопределить удовольствие onPageFinished (представление: WebView?, URL: строка?) {
         super.onPageFinished (вид, URL)
     }
}

Используя эти два метода, вы можете понять, когда страница начала и закончила загрузку, и вы можете получить доступ к URL-адресу.

Одной из распространенных реализаций onPageFinished является обновление веб-страницы, если высота содержимого равна 0 после завершения загрузки страницы, поскольку это может указывать на то, что что-то пошло не так (например, PDF-файл мог не загрузиться в WebView). :

 myWebView.webViewClient = объект: WebViewClient() {
     переопределить удовольствие onPageStarted (представление: WebView?, URL: строка?, иконка: растровое изображение?) {
         super.onPageStarted(вид, URL, значок)
     }
      переопределить удовольствие onPageFinished (представление: WebView?, URL: строка?) {
              если (вид?.contentHeight == 0) {
                  вид.перезагрузить()
              } еще {
                 super.onPageFinished (вид, URL)
              }
     }
}

Обработка навигации с помощью кнопки «Назад»

Как объяснялось ранее, WebView не имеет встроенных элементов управления навигацией. Если у вас открыта страница и вы нажимаете кнопку «Назад» на Android, она не перейдет на ранее посещенную страницу в WebView. Вместо этого он будет перемещаться внутри самого приложения, как показано ниже:

Обычно WebView реализуются в своей собственной активности. Чтобы исправить это, нам нужно внимательно изучить поведение активности, к которому мы можем получить доступ.

Класс Activity предоставляет различные способы переопределения и настройки поведения. Одним из примеров является onKeyDown ; этот метод вызывается при нажатии клавиши.

Мы можем использовать этот метод, чтобы определить, когда пользователь нажимает кнопку «Назад» на устройстве. Вот пример:

 переопределить удовольствие onKeyDown (keyCode: Int, событие: KeyEvent?): Boolean {
    если (keyCode == KeyEvent.KEYCODE_BACK && webView.canGoBack()) {
        webView.goBack()
        вернуть истину
    }
    // Если это была не клавиша «Назад» или нет истории веб-страниц, всплывающее окно до значения по умолчанию
    // поведение системы (вероятно, выход из активности)
    вернуть super.onKeyDown (keyCode, событие)
}

WebView предоставляет несколько полезных служебных методов, таких как canGoBack и goBack .

Мы можем использовать canGoBack , чтобы узнать, загружалась ли ранее страница. Мы можем использовать goBack для загрузки предыдущей страницы:

 если (keyCode == KeyEvent. KEYCODE_BACK && webView.canGoBack())

Приведенный выше код проверяет, является ли нажатая клавиша кнопкой возврата устройства и была ли загружена какая-либо страница до нажатия кнопки. Если результат положительный, Вызывается метод goBack .

onKeyDown возвращает логическое значение. Если мы хотим переопределить поведение, мы возвращаем true ; в противном случае мы возвращаем false .

Более 200 000 разработчиков используют LogRocket для улучшения цифрового взаимодействия

Подробнее →

Добавив этот код в нашу активность, мы должны увидеть следующее поведение:

Анализ посещаемых URL-адресов

В некоторых сценариях может потребоваться перенаправить пользователя во внешние приложения. Например, мы можем захотеть разрешить пользователю открывать PDF-файл.

Чтобы сделать это возможным, WebViewClient предоставляет другой метод, который можно переопределить, называемый shouldOverrideUrlLoading :

 myWebView.webViewClient = объект: WebViewClient() {
    переопределить удовольствие
        представление: WebView?,
        запрос: WebResourceRequest?
    ): логическое значение {
        …
        вернуть super.shouldOverrideUrlLoading (просмотр, запрос)
    }
}

Этот метод будет вызываться каждый раз при загрузке нового URL. Это позволяет нам проверить, какой URL загружается, и отреагировать соответствующим образом:

 myWebView.webViewClient = объект: WebViewClient() {
    переопределить удовольствие
        представление: WebView?,
        запрос: WebResourceRequest?
    ): логическое значение {
        вид?.url?.let { URL-адрес ->
           если (url.endsWith(".pdf")) {
               startActivity(Intent(Intent.ACTION_VIEW, Uri.parse(url)))
               вернуть истину
           }
        }
        вернуть super.shouldOverrideUrlLoading (просмотр, запрос)
    }
}

WebView имеет свойство с именем url , что соответствует текущему загруженному URL-адресу. Мы можем взять это свойство и подтвердить, заканчивается ли URL-адрес расширением PDF, например:

если (url.endsWith(".pdf"))

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

Отображение экрана загрузки во время загрузки страницы

Чтобы улучшить взаимодействие с пользователем, мы можем предоставить пользователю возможность узнать, что страница все еще загружается. Мы можем сделать это, переопределив onPageStarted и onPageFinished на WebViewClient , например:

 myWebView.webViewClient = объект: WebViewClient() {
     переопределить удовольствие onPageStarted (представление: WebView?, URL: строка?, иконка: растровое изображение?) {
         super. onPageStarted(вид, URL, значок)
     }
      переопределить удовольствие onPageFinished (представление: WebView?, URL: строка?) {
         super.onPageFinished (вид, URL)
     }
}

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

Вот пример:

 myWebView.webViewClient = объект: WebViewClient() {
     переопределить удовольствие onPageStarted (представление: WebView?, URL: строка?, иконка: растровое изображение?) {
         super.onPageStarted(вид, URL, значок)
         показать загрузку ()
     }
      переопределить удовольствие onPageFinished (представление: WebView?, URL: строка?) {
         super.onPageFinished (вид, URL)
         уволить загрузку ()
     }
}

Обработка сбоев процесса рендеринга

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

Обычно вы понимаете, что имеете дело с этой проблемой, если трассировка стека сбоя содержит следующее сообщение:

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

В сообщении об ошибке также может быть указан идентификатор процесса .

Чтобы гарантировать, что работа пользователя не пострадает, сбой должен быть устранен, иначе приложение будет закрыто.

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

Если происходит сбой процесса рендеринга при доступе к определенной веб-странице, попытка загрузить ту же страницу может вызвать ту же проблему.

Чтобы решить эту проблему, нам нужно переопределить onRenderProcessGone на WebViewClient , например:

 myWebView.webViewClient = объект: WebViewClient() {
    переопределить удовольствие onRenderProcessGone (представление: WebView, подробности: RenderProcessGoneDetail): Boolean {
        если (!detail.didCrash()) {
            Log.e("MY_APP_TAG", ("Система прервала процесс рендеринга WebView" +
                "восстановить память. Воссоздать..."))
            myWebView?.also {webView ->
                val webViewContainer: ViewGroup = findViewById(R.id.my_web_view_container)
                webViewContainer.removeView (веб-представление)
                webView.destroy()
                мой веб-просмотр = ноль
            }
            // К этому моменту переменная экземпляра "myWebView" гарантирована
            // быть нулевым, поэтому его можно безопасно повторно инициализировать.
            return true // Приложение продолжает выполняться. 
        }
        Log.e("MY_APP_TAG", "Сбой процесса рендеринга WebView!")
        вернуть ложь
    }
}

Если RenderProcessGoneDetail didCrash() возвращает значение false , это означает, что процесс был остановлен из-за нехватки памяти в системе. В этом случае приложение может корректно восстановиться, создав новый экземпляр WebView.

Когда из onRenderProcessGone возвращается значение true , это означает, что мы хотим, чтобы приложение работало, а не закрывалось из-за сбоя.

Если RenderProcessGoneDetail didCrash() возвращает значение true , это означает, что процесс был остановлен из-за внутренней ошибки, такой как нарушение доступа к памяти. Если в этом случае вы вернете false , приложение рухнет после обнаружения сбоя рендерера.

Чтобы более корректно обработать сбой и позволить приложению продолжить выполнение, выполните следующие действия:

Уничтожить текущий экземпляр WebView
Укажите логику продолжения выполнения приложения
Возврат true из onRenderProcessGone

Заключение

В этой статье мы исследовали и предложили решения для некоторых наиболее распространенных проблем, с которыми сталкиваются разработчики Android при использовании WebView. В частности, мы рассмотрели, как: настроить навигацию с помощью кнопки «Назад» в Android с помощью WebView, управлять навигацией по страницам и перезагрузкой страницы, если контента нет, анализировать URL-адреса, к которым осуществляется доступ, отображать экран загрузки во время загрузки страницы и обрабатывать сбои процесса рендеринга.

Чтобы узнать больше о WebView, ознакомьтесь с официальной документацией по созданию веб-приложений в WebView и управлению объектами WebView.

Преодолейте шум традиционных отчетов об ошибках с помощью LogRocket

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

Затем используйте повтор сеанса с глубокой технической телеметрией, чтобы точно увидеть, что видел пользователь и что вызвало проблему, как если бы вы смотрели через его плечо.

LogRocket автоматически объединяет ошибки на стороне клиента, исключения JS, показатели производительности внешнего интерфейса и взаимодействия с пользователем. Затем LogRocket использует машинное обучение, чтобы сообщить вам, какие проблемы затрагивают большинство пользователей, и предоставить контекст, необходимый для их устранения.

Сосредоточьтесь на важных ошибках — попробуйте LogRocket сегодня.

LogRocket: Мгновенное воссоздание проблем в ваших приложениях для Android.

LogRocket — это решение для мониторинга Android, которое помогает мгновенно воспроизводить проблемы, определять приоритеты ошибок и анализировать производительность приложений Android.

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

Начните активно отслеживать свои приложения для Android — попробуйте LogRocket бесплатно.

Анализ производительности: получите полезную информацию о производительности вашего веб-сайта

Используйте панель Анализ производительности , чтобы получить полезную информацию о производительности вашего веб-сайта на основе сценариев использования.

Эта функция доступна только в Chrome, но не в Chromium.

Это предварительная функция в Chrome 102. Наша команда активно работает над этой функцией, и мы ждем ваших отзывов для дальнейших улучшений.

# Зачем новая панель?

Новая панель Performance Insights представляет собой эксперимент по устранению этих 3 болевых точек разработчика при работе с существующей панелью Performance :

Слишком много информации . Благодаря переработанному пользовательскому интерфейсу панель Performance Insights оптимизирует данные и отображает только актуальную информацию.
Трудно различить варианты использования . Панель Performance Insights поддерживает анализ вариантов использования. На данный момент он поддерживает только вариант использования загрузки страницы, и в будущем будет больше, основываясь на ваших отзывах, например, интерактивность.
Для эффективного использования требуется глубокое знание того, как работают браузеры. Панель Performance Insights выделяет ключевые идеи на панели Insights с действенными отзывами о том, как исправить проблемы.

# Введение

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

# Откройте панель статистики производительности

Откройте DevTools.
Щелкните Дополнительные параметры > Дополнительные инструменты > Анализ производительности .
Можно также использовать меню команд, чтобы открыть панель Анализ производительности .

# Запись производительности

Панель Анализ производительности может записывать общую производительность и производительность на основе вариантов использования (например, загрузку страницы).

Откройте эту демонстрационную страницу на новой вкладке и на странице откройте панель Анализ производительности.
Вы можете дросселировать сеть и ЦП во время записи. Для этого руководства установите флажок Отключить кеш и установите ЦП на 4-кратное замедление в раскрывающемся меню:
Регулировка зависит от возможностей вашего компьютера. Например, опция замедления 4x заставляет ваш процессор работать в 4 раза медленнее, чем обычно. DevTools не может по-настоящему имитировать ЦП мобильных устройств, потому что архитектура мобильных устройств сильно отличается от архитектуры настольных компьютеров и ноутбуков.
Нажмите Измерьте загрузку страницы . DevTools записывает показатели производительности во время перезагрузки страницы, а затем автоматически останавливает запись через пару секунд после завершения загрузки страницы.
Если вы хотите измерить общую производительность вашей веб-страницы, используйте Начать запись . Взаимодействуйте со страницей и нажмите Остановить запись вручную, чтобы остановить запись.

# Воспроизведение записи выступления

Используйте элементы управления внизу, чтобы управлять воспроизведением вашей записи.

Вот пример того, как это сделать.

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

# Навигация по записи выступления

DevTools автоматически уменьшает масштаб, чтобы показать полную временную шкалу записи. Вы можете перемещаться по записи с увеличением и перемещать временную шкалу.

Для масштабирования и перемещения временной шкалы влево и вправо используйте соответствующие кнопки навигации:

Нажмите на временную шкалу , чтобы переместить указатель воспроизведения для просмотра определенного кадра.
Щелкните элементы управления Увеличить и Уменьшить внизу, чтобы увеличить масштаб. В этом случае вы масштабируете на основе указателя воспроизведения.
Перетащите горизонтальную полосу прокрутки внизу, чтобы переместить временную шкалу влево и вправо.

Кроме того, вы можете использовать сочетания клавиш. Нажмите на ? Кнопка для просмотра ярлыков.

При использовании ярлыков масштабирование зависит от курсора мыши.

# Просмотр сведений о производительности

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

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

Нажмите на информацию, например запрос на блокировку рендеринга, чтобы открыть его в Сведения 9панель 0262. Чтобы лучше понять проблему, изучите его File , Issue , Как исправить разделы и многое другое.

# Просмотреть показатели производительности Web Vitals

Web Vitals — это инициатива Google, направленная на предоставление унифицированных рекомендаций по сигналам качества, которые необходимы для обеспечения удобного взаимодействия с пользователем в Интернете.

Эти показатели можно просмотреть на панели Timeline и Insights .

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

# Обнаружение задержек крупнейшей отрисовки контента

Крупнейшая отрисовка контента (LCP) — это одна из основных метрик Web Vitals. Он сообщает время рендеринга самого большого изображения или текстового блока, видимого в области просмотра, по отношению к тому моменту, когда страница впервые начала загружаться.

Хороший показатель LCP составляет 2,5 секунды или меньше.

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

Чтобы открыть панель Details , щелкните значок LCP на временной шкале или на панели Insights справа. На панели вы можете обнаружить потенциальные причины задержек и предложения по их устранению.

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

Чтобы просмотреть части времени рендеринга LCP, прокрутите вниз до Details > Поломка тайминга разд.

Время рендеринга LCP состоит из следующих подчастей:

Подчасть LCP	Описание
Время до загрузки первого байта с момента, когда пользователь инициирует 90 с до тех пор, пока браузер не получит первый байт ответа HTML-документа.
Задержка загрузки ресурса	Дельта между временем TTFB и моментом, когда браузер начинает загрузку ресурса LCP.
Время загрузки ресурса	Время, необходимое для загрузки самого ресурса LCP.
Задержка рендеринга элемента	Дельта между завершением загрузки ресурса LCP и полной визуализацией элемента LCP.

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

# Просмотр активности смены макета

Просмотр активности смены макета в дорожке Layout Shifts .

Сдвиги макета группируются в окне сеанса. В приведенном выше примере есть два окна сеанса. Окна сеанса имеют промежутки между ними.

Думайте о смене макета как о фейерверке. Бывают случаи, когда несколько смен происходят одновременно, затем они приостанавливаются на некоторое время, а затем снова происходят несколько смен. Каждый набор из нескольких смен представляет собой окно сеанса. Дополнительные сведения см. в разделе Окно сеанса.

Совокупные изменения макета (CLS) — это один из основных показателей Web Vitals. Используйте дорожку Layout Shifts , чтобы определить потенциальные проблемы и причины смещения макета.

При улучшении показателя CLS всегда начинайте с самого большого окна сеанса. В нашем примере окно сеанса 1 является самым большим окном в зависимости от цвета и уровня фона.

Щелкните снимок экрана, чтобы просмотреть сведения об изменении макета, определить потенциальные основные причины и затронутые элементы.

В нашем примере потенциальная первопричина — нестандартный носитель . Чтобы узнать, как это исправить, см. раздел Оптимизация совокупного смещения макета.

# Понимание оценки смены макета

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

Если сдвигается вся страница, максимальное количество баллов за каждое изменение макета составляет 1 . В нашем примере первая смена макета набрала 9 баллов.0041 0,15 . Вторая смена компоновки набрала 0,041 .

Общий балл за это окно сеанса: 0,19 . Судя по порогу CLS, он нуждается в улучшении. Цвет фона окна сеанса отражает то же самое.

Фоновая диаграмма окна сеанса со временем увеличивается. Совокупный балл смены макета отражает увеличение на тот момент времени.

# Просмотр сетевой активности

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

# Просмотр активности рендерера

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

# Просмотр активности GPU

Просмотр активности GPU на дорожке GPU . Дорожка графического процессора по умолчанию скрыта. Чтобы включить его, установите флажок GPU 9.0262 в настройках.

# Просмотр таймингов пользователей

Чтобы получить пользовательские показатели производительности, вы можете использовать User Timing и визуализировать свои тайминги с помощью трека Timing . Для получения дополнительной информации см. API хронометража пользователя.

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

Для просмотра пользовательского тайминга:

Отметьте места в вашем приложении с помощью performance.mark() .
Измерьте прошедшее время между метками с помощью производительность.measure() .
Рекорд производительности.
Просмотр измерений на дорожке Timings . Если вы не видите трек, проверьте Пользовательские тайминги в Настройках.
Чтобы просмотреть подробности, щелкните время на дорожке.