Отслеживание пользователей, поступающих из определенного источника

Ответ 1

Строка запроса

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

Hash

• Аналитики и журналы сервера не будут видеть/обращать внимание на параметры hash

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

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

Ответ 2

Стандартный способ сделать это для запроса GET - просто использовать строку запроса.

http://www.mysite.com?app_source=user_id

Если вы используете привязку URL, например

http://www.mysite.com#app_source,user_id

Якорная часть (#app_source,user_id) не отправляется на сервер

Например, см. этот связанный вопрос.

Вот еще один связанный вопрос

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

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

PHP дает вам прямой доступ к строке запроса с помощью $_SERVER['QUERY_STRING']

Rails использует request.uri, который вы можете проанализировать

Кроме того, когда вы видите причудливые вещи, такие как facebook.com/#stuff, часть привязки обрабатывается с помощью javascript на стороне клиента. Таким образом, вы можете сделать это, но вы будете писать ajax-код, который отправляет обычные запросы GET, такие как рекомендованные в верхней части этого ответа.

Зачем добавлять сложность? Вам просто нравится стиль # лучше, чем ??

Ответ 3

Используйте подход ?. Зачем? Потому что вы должны передавать произвольные данные по страницам.

# специально используется для привязок страниц.

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

Итак, я бы выполнил описанный ниже подход :

function $_GET(q,s) {
    s = s ? s : window.location.search;
    var re = new RegExp('&'+q+'(?:=([^&]*))?(?=&|$)','i');
    return (s=s.replace(/^?/,'&').match(re)) ? (typeof s[1] == 'undefined' ? '' : decodeURIComponent(s[1])) : undefined;
}

var app_source = $_GET('app_source');

Тогда у вас могут быть такие URL-адреса: http://www.mysite.com?app_source=user_id#anchor

Ответ 4

W3C говорит здесь:

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

Ответ 5

Используйте HASH.

Почему?

Потому что вы разрабатываете сторонний плагин и не знаете, являются ли какие-либо из аргументов НЕ пользователями разработчиками сайта. Когда вы переопределяете один из используемых параметров get, вы можете уничтожить важную информацию, переданную на сервер с помощью встроенных приложений. Кроме того, вы не хотите, чтобы приложение обладало дублируемыми страницами: http://somepage.com/ и http://somepage.com/?app_source=user_id будет дублировать, и как многие пользователи будут ссылаться на эту страницу, вы создадите многие из них.

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

Ответ 6

Хеш - это путь.

Есть только 2 варианта: один - параметр GET, а второй - #.

? ПОЛУЧИТЬ ПАРАМЕТР

Параметр get может быть проиндексирован поисковой системой, а два URL http://www.yoursite.com/ и http://www.yoursite.com/?app_id=123 могут быть 2 отдельными страницами

На одном из моих сайтов я использовал это, и я получаю письма от google, заявляя While crawling your site, we have noticed an increase in the number of transient soft 404 errors around 2012-06-30 22:00 UTC (London, Dublin, Edinburgh). Your site may have experienced outages. These issues may have been resolved. Here are some sample pages that resulted in soft 404 errors:

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

# HASH

Хэши лучше, поскольку они не изменяют поведение какой-либо вещи SEO (многие ppl скажут, что это имеет влияние, но я так не думаю)

В конце вам просто нужно получить app_source и передать его на ваш сервер с помощью Javascript. Так вы можете как хотите. Если бы я был вами, я бы с удовольствием использовал HASH

Ответ 7

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

Если вы хотите различать App и UserId:

http://www.mysite.com/appName/UserID/

Или только с помощью UserId:

http://www.mysite.com/UserID/

Но я лично подойду как к AppName, так и к UserName:

http://www.mysite.com/appName/UserName/

Ответ 8

Основываясь на некоторых современных веб-приложениях сегодня, которые продвинули знак "#", очень полезно поддерживать SPA (одностраничное приложение), например, Twitter. Пожалуйста, просто используйте "?" знак.

Ответ 9

Простым способом является использование параметра GET с идентификатором пользователя, чтобы проверить, был ли он передан кем-то.

http://www.mysite.com/?ref=1128721

Затем, если вы хотите узнать больше о реферере, вы также можете проверить, с какого URL пользователь действительно нажал вашу ссылку, используя $_SERVER['HTTP_REFERER'] (если вы используете php). Таким образом, вы можете убедиться, что ваша ссылка не была в нежелательном месте или "автоматически посещена".