Лучший способ обнаружить и сохранить комбинации путей для последующего анализа цели - PullRequest
0 голосов
/ 30 октября 2010

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

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

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

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

Будете ли вы сначала регистрировать что-то «большое время», а затем через некоторое время обрабатывать каждую деталь, или у вас есть большой опыт работы с другими тактиками?

Меня беспокоит, что это займет много места, БОЛЬШОЕ ВРЕМЯ, при этом регистрируя 1000 пользователей каждый день в течение месяца или более.

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

Нашими инструментами будут C #, SQL-база данных, XML и .NET 3.5 - клиенты также могут получить .NET 4.0, если необходимо.

Примеры шаблонов в том виде, в каком мы их ожидаем

...
User #1001: A-B-A-A-A-B-C-E-F-G-H-A-A-A-C-B-A
User #1002: B-A-A-B-C-E-F
User #1003: F-B-B-A-E-C-A-A-A   
User #1002: C-E-F
...

и т.д.. нет реального способа узнать, что они делают дальше, и сколько они будут использовать, как часто они будут это делать.

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

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

Ответы [ 2 ]

1 голос
/ 30 октября 2010

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

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

0 голосов
/ 01 ноября 2010

Псевдо идея / реализация до сих пор

  1. Регистрируйте когда-либо действия пользователей в списке / серии действий, в общем виде (стиль текстовых файлов / SQL - что угодно,просто сохраните все это для последующей обработки)

  2. начните отсчитывать каждое «1 действие», «2 действия», «3 действия» до определенной суммы (скажем, 30 уровней)

  3. отсортировать их все, указав значения для некоторых действий (возможно, для конечных результатов)

Aвозможно, полезный результат?

Если мы посчитаем все [A], [AA], [AB], [AC], [AAA], [AAB] и т. д., то получится длинный и штрафсписок действий, которые часто используются в строке, и это в правильном направлении, потому что, если некоторые из этих результатов становятся слишком высокими, нам может понадобиться более короткий путь.Проблема в том, что слишком мало действий, которые нужно оптимизировать, и какой список действий самый длинный для поиска?Я предполагаю, что нам нужно сначала сделать этот подсчет, а затем изучить числа.

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

...