Официальный сайт движения «Москва без Лужкова!»
Главная Новости Москвы Наши новости Популярное
  • Новости
  • Новости
  • ВХОД В ЛИЧНЫЙ КАБИНЕТ
    логин
    пароль
       
    Новости

    Google Analytics: работа со структурированными URL и лендингами

    1. Какую информацию мы действительно имеем о наших посадках?
    2. Если у меня есть только URL-адреса, какие URL-адреса мне понадобятся?
    3. Изменение URL только в Google Analytics
    4. Захват 2 URL-адресов одновременно в Google Analytics
    5. Как мы это делаем?
    6. Не будут ли они слишком длинными?
    7. Фильтрация URL для каждого профиля
    8. Почему я не могу увидеть это в реальном времени?
    9. Что мне теперь делать?
    10. Давайте начнем: Работа с просмотром страниц
    11. Мы продолжаем: Работаем с бизнес-ориентированными URL
    12. С продвинутыми сегментами
    13. Сегменты из API
    14. С пользовательских отчетов
    15. Что если мы сделаем еще один шаг? Перемещение информации о посадках в переменные измерения кампании
    16. Как мне найти свою посадку в системе фильтров?
    17. Начинаем создавать посадочные размеры
    18. И это сделано!
    19. БОНУС: Код для создания бизнес-URL в WordPress
    20. Вывод: нам предстоит пройти долгий путь, полный новостей, радостей и разочарований

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

    Лендинги - это страницы, на которые пользователь попадает, когда он заходит на наш сайт. Приходите откуда угодно: поисковые системы, кампании, социальные сети и т. Д. Первый контакт пользователя с нашим сайтом во время его посещения - это целевая страница. Это означает, что они являются четким индикатором как мотивации, так и первого опыта пользователей в Интернете. По этой причине жизненно важно найти систему для классификации и организации отчетов вокруг них.

    По умолчанию эти места приземления рассматриваются в Google Analytics как измерение «Страница назначения». Измерение, которое содержит URL-адреса этих первых страниц, просматриваемых пользователями. Мы можем проверить их в своем собственном отчете в разделе «Контент> Контент сайта> Целевые страницы», разбитый по одному.

    Для меня это один из самых важных отчетов, которые Analytics может предложить нам, потому что, как мы уже говорили, данные о пользователе - это огромное количество информации:

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

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

    Какую информацию мы действительно имеем о наших посадках?

    К сожалению, очень мало. У нас есть только один грустный и одинокий URL. Да, мы все знаем, чтобы увидеть этот URL, куда он нас ведет, но, в зависимости от того, как был запрограммирован наш сайт, наши URL могут быть довольно загадочными. Мы можем встретиться с:

    • URL-адреса, образованные переменными: их трудно обрабатывать в аналитике, а иногда они даже скрывают данные с помощью таких вещей, как "& cat = 23".
    • URL-адреса дружественные, но неорганизованные: где по причинам SEO URL-адреса формируются из слов и ключевых слов, но не соответствуют реальной структуре, например, «/ printer-cheap-details» на веб-сайтах с тысячами или миллионами страниц этого типа.
    • URL с Структура URL SEO хорошо сделана но это соответствует критериям организации SEO, а не бизнесу. Другими словами, папки были созданы для семантической унификации страниц, но не для того, чтобы помочь нам увидеть, какие это страницы или их ориентацию на достижение целей и где «/ category-x / product-y» часто трудно отличить от «/ who -Мы / контакт "

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

    Если у меня есть только URL-адреса, какие URL-адреса мне понадобятся?

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

    • Какой тип страницы или контента
    • По какой основной тематической структуре организована (основные категории)
    • Что представляет собой дизайн, формат или макет страницы (если есть различия в наших проектах)
    • И, наконец, какая страница на самом деле (уникальным способом, без повторяющихся URL)

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

    / [type-page] / [cats] / [page] -layout- [design]

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

    Итак, URL ... Должны ли они быть именно такими? Когда - нибудь?

    Нет! Совсем нет. В зависимости от типа веб-сайта мы можем организовать URL-адреса по-разному. Мы могли бы говорить о разделах вместо типов страниц. Не располагайте категориями или категориями, настолько большими, чтобы для их рассмотрения потребовалось несколько уровней. Мы не можем использовать различные дизайны или хотим сохранить больше деталей, связанных с URL-адресами: есть ли формы или нет, являются ли они страницами решений о покупке или нет, и т. Д. В конце концов, выбранная структура должна появиться из вашего бизнес-анализа, который покажет вам, что важно знать о ваших посадках, но я, чтобы продолжить с примерами и объяснениями, предпочел указать структуру как можно более общей.

    Ну, мы уже знаем, как мы хотим, чтобы наши URL были такими, чтобы наша информация о посадках была действительно полезной. Проблема в том, что для улучшения этой информации лишь немногие веб-сайты решат изменить все свои URL, чтобы помочь нам. И еще, если мы знаем, что изменение URL-адресов может сильно повлиять на наш бизнес: это критическое изменение для SEO, а также требует от нас изменить все платежные ссылки, которые мы можем иметь, и хорошо позаботиться о перенаправлениях ... Слишком много неприятностей. Конечно, из аналитики мы не должны делать подобные предложения.

    Изменение URL только в Google Analytics

    Решение, как вы уже догадались, на самом деле не меняет URL вашего сайта. Возможно, ваш сайт нуждается в этом, но, как мы уже говорили, просто для улучшения возможностей анализа мы не должны влиять на сайт технически. Мы сделаем так, чтобы Google Analytics работал так, как если бы эти URL были такими, какими мы хотим их видеть. Мы собираемся манипулировать Analytics, чтобы все URL-адреса, захваченные в системе, выглядели так, как нам удобно.

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

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

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

    Захват 2 URL-адресов одновременно в Google Analytics

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

    Короче говоря:

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

    Как мы это делаем?

    Идея состоит в том, чтобы включить оба URL-адреса в качестве URL-адресов страниц, разделяя их набором символов, которые обычно не используются в URL-адресах и которые позволяют создавать соответствующие расширенные фильтры для использования одного или другого URL-адреса:

    URL, который я предлагаю, будет иметь такой формат:

    / url-real || / url-new

    Как получить бизнес-ориентированный URL

    Не заблуждайтесь, новый URL должен быть создан и не будет генерироваться магией, кто-то должен с ним работать. Чтобы достичь этого, нам нужно будет использовать технику, которая позволяет нам генерировать это:

    • В большинстве случаев лучшим решением будет программирование нашего сайта. Не для возможности отправки самих данных, а для генерации нового URL-адреса, который будет динамическим и, следовательно, должен генерироваться по-разному на каждой реальной странице. Что может быть лучше, чтобы узнать различные переменные, которые мы хотим включить, чем программирование, которое генерирует эти страницы?
    • Другой метод основан на JavaScript. Если вся информация, которую мы ищем, будет размещена в Интернете. Например: в хлебных крошках, на специальных страницах и в частях реального URL мы могли бы создать небольшой сценарий javascript, который бы собирал все эти части и форматировал их в самой аналитике _trackPageview.
    • Наконец, если наш URL-адрес уже содержит все эти переменные, но неорганизован, мы можем использовать расширенные фильтры, чтобы с помощью регулярных выражений мы могли выбирать параметры URI запроса и вместе с ними формировать новый URI запроса. Это может быть сложно, если вы не очень хорошо знаете регулярные выражения, а во многих случаях это просто невозможно, но если мы его получим, это будет самый быстрый вариант.

    Что ж, давайте помнить, что в большинстве случаев нам понадобится помощь технического / программиста / разработчика, чтобы помочь нам генерировать новые URL-адреса именно так, как они нам нужны.

    Мы начнем с того, что эта работа по созданию URL уже выполнена, и у нас есть URL, сгенерированный в переменной PHP: $ url. В этом случае наш просмотр страницы будет следующим:

    В текущей аналитике (ga.js):

    _gaq.push (['_ trackPageview', location.pathname + '|| <? echo $ url?>']));

    и в Универсальном (analytics.js):

    ga ('send', 'pageview', {'page': location.pathname + '|| <? echo $ url?>',});

    Это автоматически захватит URL-адрес, который должен уже захватить сам Google Analytics (и который доступен в location.pathname), добавит набор символов «||» и после этого URL-адрес содержится в переменной $ url.

    Конечно, в других языках, кроме PHP, способ печати переменной будет другим.

    Если у нас все получилось, мы запишем эти типы URL в нашей аналитике:

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

    Не будут ли они слишком длинными?

    Прежде чем спросить, я отвечу. Аналитика должна быть готова для захвата URL длиной чуть более 2000 символов. Это потому, что URL действительно может иметь это измерение. Как правило, веб-сайты не используют более 200 символов в своих URL-адресах, поэтому мы можем позволить себе вложить 2 из них и продолжить сбор полных данных. За исключением, конечно, того, что ваш сайт - одна из тех странностей, которые уже объединяют 2000 символов для своих URL-адресов ... в таком случае ... Я не могу вам чем-то помочь 😉

    Фильтрация URL для каждого профиля

    Как мы видим, URL-адреса, которые у нас сейчас есть, не являются ни красивыми, ни чем-то, с чем мы можем работать, поэтому мы можем создать необходимые фильтры, чтобы отображать в наших отчетах только те данные, которые нам нужны и действительно нужны:

    Фильтр 1: Сохранить реальный URL в профиле

    Фильтр 1: Сохранить реальный URL в профиле

    Фильтр 2: сохранить обработанный URL в профиле

    Фильтр 2: сохранить обработанный URL в профиле

    Фильтры очень похожи ... Ну, это почти тот же фильтр. В обоих случаях мы фиксируем две части URL, разделенные "||" с выражением: "(. *) \ | \ | (. *)" Только в первой мы собираем первую часть с $ A1, а во второй - с $ A2.

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

    Почему я не могу увидеть это в реальном времени?

    Конечно, это не произойдет с вами, но возможно, что в отчете в реальном времени вы не увидите, что эти фильтры вступают в силу. Это случилось со мной на целый день, и это довольно расстраивает Конечно, это не произойдет с вами, но возможно, что в отчете в реальном времени вы не увидите, что эти фильтры вступают в силу

    В конце концов мне пришлось с этим справиться, потому что мне не подходило не видеть данные, как они играли в Universal. к счастью Моника Аревало ( @Nikalytics ), что, если вы еще ее не знаете, она является аналитиком по крэкам, много часов отдавая Google Analytics, и подтвердила, что иногда при таком большом тестировании и изменении конфигурации Google Analytics она снова и снова насыщается, и вы должны покинуть ее время для меня, чтобы вернуться на работу, как мы ожидаем.

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

    Что мне теперь делать?

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

    Давайте начнем: Работа с просмотром страниц

    Наш анализ просмотров страниц, например, будет значительно улучшен. Быстрый взгляд должен позволить нам намного лучше анализировать наши страницы. Как только у нас появятся данные, перейдем к «Контент> Контент сайта> Разбивка контента».

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

    Кроме того, если вы один из тех, кто обрабатывает свои собственные данные с помощью API, у вас будет 4 измерения, чтобы выполнить эту работу самостоятельно:

    - ga: pagePathLevel1
    - ga: pagePathLevel2
    - ga: pagePathLevel3
    - ga: pagePathLevel4

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

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

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

    Мы продолжаем: Работаем с бизнес-ориентированными URL

    К сожалению, аналитика не предлагает измерения типа «ga: landingpagePathLevel1», чтобы можно было выполнять ту же работу, что и с отдельными страницами через приземления. Это было бы настоящей роскошью, но это просто невозможно. Возможно, если бы мы отправили 3 миллиона электронных писем людям из Google Analytics, мы бы добавили эти измерения, но на данный момент они не существуют. Чеснок и вода.

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

    С продвинутыми сегментами

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

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

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

    Таким же образом я могу работать на любом уровне своей структуры: категориях, элементах или даже разных дизайнах страниц (помните, что в URL мы указали как -layout- [design]):

    Таким же образом я могу работать на любом уровне своей структуры: категориях, элементах или даже разных дизайнах страниц (помните, что в URL мы указали как -layout- [design]):

    Сегменты из API

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

    Паро. Я также не буду вдаваться в подробности: те, кто знает, как использовать API, уже будут видеть возможности и потирать руки с возможностями новых таблиц и панелей мониторинга, а также тех, кто не должен связываться с API только для этого.

    С пользовательских отчетов

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

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

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

    Что если мы сделаем еще один шаг? Перемещение информации о посадках в переменные измерения кампании

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

    Предупреждение: мы должны быть очень осторожны! При изменении измерений, которые не были созданы для определенной цели, вполне вероятно, что при внесении изменений мы потеряем информацию о наших реальных данных Google Analytics. Жаль, что Analytics не предлагает несколько дополнительных параметров кампании, которые можно заполнить в соответствии с вашими потребностями, но так оно и есть.

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

    Как мне найти свою посадку в системе фильтров?

    Sopresa! Аналитика в своей системе фильтров не позволяет нам видеть данные сеанса, только для каждого аналитического попадания отдельно. Это означает, что при настройке фильтра мы знаем только, какой URL отправляется каждый раз (на каждой просмотренной странице), но не знаем, является ли это посадкой или нет. Как будто этого было недостаточно, данные кампании, даже если нам удалось изменить их только в лендинге, так как при каждом попадании они извлекаются из файла cookie аналитики, если они не будут перегружены на каждой странице, они вернутся к своему первоначальному значению на второй странице, которая увидеть пользователя ...

    Приходите, с имеющейся у нас информацией, невозможно заполнить переменные нашей кампании на всех страницах посещения, основываясь на информации о посадках. Поэтому нам нужно добавить дополнительную информацию в Google Analytics. Код, который мы первоначально захватили как URL, будет недостаточным ... мы должны рассмотреть его:

    • Для захвата: [url-old] || [url-business]
    • Теперь мы должны записать: [url-old] || [url-business] || [url-landing]

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

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

    Помните, что у нас должна быть доступная переменная PHP $ url с уже подготовленными нашими бизнес-URL-адресами, поэтому мы будем использовать ее в качестве бизнес-URL-адреса и на которой будем основываться для создания целевого URL-адреса:

    var newURL = '<? echo $ url?> '; вар геландинг; if (gaLanding = document.cookie.match (/_gal=([^;]+)(;.+)?$/)) gaLanding = gaLanding [1]; else {gaLanding = newURL; document.cookie = '_gal =' + newURL + '; путь = /'; } _gaq.push (['_ trackPageview', location.pathname + '||' + newURL + '||' + gaLanding]);

    Хорошо, мы уже изменили наши URL. Но это будет означать, что мы должны заново отредактировать фильтры нашего профиля, чтобы в Google Analytics сохранялись правильные URL-адреса. Теперь есть 3 URL, а не два, поэтому фильтр, который мы создали для выбора URL, больше не будет действительным.

    Это будет просто, мы просто укажем:

    Для профилей с реальными URL

    • Поле A: (. *) \ | \ | (. *) \ | \ | (. *)
    • Выдержка: $ A1

    Для профилей с бизнес-URL

    • Поле A: (. *) \ | \ | (. *) \ | \ | (. *)
    • Выдержка: $ A2

    Очень просто А сейчас? Кажется, ничего не изменилось, верно? Дело в том, что в данный момент он этого не сделал, единственное, что происходит, это то, что теперь я имею доступ к информации Landing Page в каждом хите аналитики, только тогда я очищаю ее, чтобы она не беспокоила. Но перед этой уборкой я могу использовать посадку для чего угодно, есть хитрость.

    Начинаем создавать посадочные размеры

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

    • Из "/ [type-page] / [category] / [page] -layout- [design]"
    • Мы хотим извлечь "[type-page] / [category]" как новое измерение

    С этими данными мы собираемся заполнить переменную кампании utm_content . Почему это? Ну, потому что это тот, который обычно наименее используется. Analytics не использует его при создании кампаний по умолчанию, Adwords использует его, чтобы указать первое предложение опубликованной рекламы (немного бесполезных данных), и большинство ярлыков кампаний, которые сделаны в агентствах, для сохранения работы, не достигают этот уровень, за исключением тестов A / B и тому подобных вещей.

    Можете ли вы использовать другое измерение? Да, конечно, вы можете использовать все, что хотите ... просто имейте в виду, что вы вызываете и что вы теряете, аннулируя это измерение, прежде чем делать это.

    Итак, мы создали следующий фильтр в одном из наших профилей:

    Хорошо! Правда, в этом случае регулярные выражения и настройки не так просты, как обычно 😉

    Мы сказали, что вам нужно немного поднять уровень, верно?

    Я разбил его на части, чтобы вы могли лучше их увидеть (и предоставить возможную вырезку и вставку):

    • Поле A: URI запроса: ^. + \ | \ |. + \ | \ | /([^/]+)(/([^/]*)(/.*)?)?$
    • Поле Б: -
    • Отправить результаты в: Содержание объявления: $ A1 / $ A3
    • Поле A Обязательное: Да
    • Поле Б Обязательное: Нет
    • Перезаписать: Да

    И для тех, кто заинтересован, я объясню это немного.

    Поле A: Напомним, что наши «URI запроса» теперь состоят из трех разных наборов URL. Таким образом, первая часть выражения создана, чтобы отбросить две начальные игры URL. С "^. + \ | \ |. + \ | \ |" мы идентифицируем эти две части, не используя их для перезаписи чего-либо («[url-real] || [url-business] ||» уже рассматривается в регулярном выражении с этой частью).

    Вторая часть поля A: "/([^/]+)(/([^/]*)(/.*)?)?$", это та, которая определяет первые две папки URL-адреса отдельно и позволяет нам использовать их как $ A1 и $ A3. Вы должны думать, что это сложно (со многими "?"), Потому что оно должно разрешить оба URL типа "/ single-type-page" и "/ type / category" как "/ type / category / what-you-want ..." ». И поэтому было необходимо идти с условным каждым шагом, который делает его очень трудным для чтения. Извините, операция была сложной, и мне не удалось упростить ее дальше.

    Send Results to: это формат, который мы собираемся дать нашему utm_content, который, как мы уже сказали, должен быть сформирован с помощью «[type page] / [cat]», который регулярным выражением, которое мы использовали в поле A, представлен как $ A1 и $ A3.

    Примечание. Этот новый созданный вами фильтр необходимо упорядочить перед фильтром, который очищает URL-адреса, в противном случае он обнаружит, что URL-адрес уже преобразован и не будет иметь места, откуда можно получить посадку. Anañytics позволяет вам сортировать различные фильтры в администраторе, поэтому вам просто нужно включить это в список непосредственно перед фильтром, с помощью которого вы выбрали, какой URL вы хотите видеть в профиле.

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

    И это сделано!

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

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

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

    Я оставляю ссылку, чтобы вы могли импортировать образец отчета:

    Что должно спровоцировать отчет вроде следующего:

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

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

    БОНУС: Код для создания бизнес-URL в WordPress

    Поскольку в настоящее время WordPress является одной из наиболее часто используемых CMS, и я знаю, что барьер для того, чтобы прибегать к программированию для создания бизнес-ориентированных URL-адресов, я оставлю вам небольшой образец кода, который поможет вам. сделайте ваши первые шаги с URL-адресами. Этот код будет генерироваться для любых почтовых URL типа:

    [url-real] || / [type-of-cotenido] / [Category] / [Url-del-Post] || [url-landing]

    Что такое в основном тот же тип URL, который мы прокомментировали (но без формата оформления, так как это очень специфично, и я не могу поместить его в общий). Есть код:

    _gaq.push (['_ setAccount', 'UA-1590899-2']); <? php $ url = false; switch (true) {// query_vars: http://codex.wordpress.org/WordPress_Query_Vars case is_category (): $ url = '/posts/'.get_term(get_query_var('cat'), 'category') -> slug ; перерыв; case is_tag (): $ url = '/tags/'.get_term(get_query_var('tag_id'), 'post_tag') -> slug; перерыв; case is_single (): глобальный $ post; $ cats = get_the_category ($ post-> ID); $ url = (isset ($ cats [0]))? «/Posts/'.$cats[0]->slug. '/'. $ post-> post_name: '/ posts / no-category /'. $ post-> post_name; перерыв; case is_page (): глобальный $ post; $ url = '/ pages /'. $ post-> post_name; перерыв; } if (! $ url) $ url = ($ _SERVER ['REQUEST_URI'] == '/')? '/ home': '/ others'. $ _SERVER ['REQUEST_URI']; ?> var newURL = '<? echo $ url?> '; вар геландинг; if (gaLanding = document.cookie.match (/_gal=([^;]+)(;.+)?$/)) gaLanding = gaLanding [1]; else {gaLanding = newURL; document.cookie = '_gal =' + newURL + '; путь = /'; } _gaq.push (['_ trackPageview', location.pathname + '||' + newURL + '||' + gaLanding]);

    Вывод: нам предстоит пройти долгий путь, полный новостей, радостей и разочарований

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

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

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

    Хотите добавить больше информации в свои URL? Тип фотографий, которые он включает? Если вы предлагаете конверсионные формы напрямую? ¿Метки? Другие виды таксономий? Всякий раз, когда есть причина для анализа, это будет хорошо.

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

    Какую информацию мы действительно имеем о наших посадках?
    Если у меня есть только URL-адреса, какие URL-адреса мне понадобятся?
    Не будут ли они слишком длинными?
    Что мне теперь делать?
    Какую информацию мы действительно имеем о наших посадках?
    Если у меня есть только URL-адреса, какие URL-адреса мне понадобятся?
    Должны ли они быть именно такими?
    Как мы это делаем?
    Что может быть лучше, чтобы узнать различные переменные, которые мы хотим включить, чем программирование, которое генерирует эти страницы?
    Pathname + '|| <?

     

    Найди свой район!

    Восточный

    Западный

    Зеленоградский

    Северный

    Северо-Восточный

    Северо-Западный

    Центральный

    Юго-Восточный

    Юго-Западный

    Южный

    Поиск:      


     
    Rambler's Top100
    © 2007 Движение «Москва без Лужкова!»