Request: Search statistics

[someone]

I've requested this maybe about a year ago or so, and since it never got any interest I'm trying again:

SEARCH STATISTICS!

Basicly, I want to know what is going on at our forums and want to know what people are looking for....

Statistics could looks like this:

Top 100 keywords searches: today|this week|this month|overall
Top 100 user name searches: today|this week|this month|overall

Interesting, or not?

[Joe]

Great idea, i would love to see this :)

[PeterNRG]

Anyone interested in developing this hack?

[eva2000]

this would be nice to have :)

[dost]

Very good idea

[RS25com]

Still waiting!!! :lol:

[Erwin]

There is a hack for the last 10 searches... but yeah, no one's done a stats one yet. :)

[sparky2]

Have you ever looked at the content of a search table record?
It's a REALLY awkward dataset to work with.

As-is, the search function doesn't store a forumid for the target subforum which was searched. Instead, it stores the longwinded SQL query code necessary for identifying the target real-time (in case the forums hierarchy is changed, in between the user's initial search... and some later date when they return and rerun that identical search ???)
^--- along the lines of where forumid!='32' AND forumid!='33' AND...
(the query becomes awkward/complex when nested/parent forums are searched)

For search usage reporting to be really useful, I think it's critical to provide stats that address questions like "What subforums are people searching in? What subforums are most-heavily searched? What keywords are most frequent for users searching subforumX v/s subforumY ?"

With this in mind, I REALLY believe that a reporting hack/add-in will be impractacal until/unless the structure of the search table is first changed ~~ extra columns added... and the search.php routines changed so that the new fields (columns) are populated.

Another limitation imposed by the status quo, in terms of reporting historical usage, is that all 7-day-old+ search resultsets (records, rows within the search table) are deleted each time the seearch.php script runs.

I've created a sort of "mirror" table (named it 'searchhistory') and periodically use a manual SQL query to copy selected fields for all rows over to the other table...

...and although I intended to have search.php update both the search and searchhistory tables with each run, I dropped the project short of figuring out a way to grab the
forum.description value associated with the subforum/branch target of the search.
^---- It can't be all that difficult. The descriptive text is right there, in the selectbox label
(document.forms(0).selectbox.options.optionselecte d.text)
just need to stuff it into a variable onSumbit


If anyone wants to work together on this (please, please) I'll be glad to.

BTW:
another missing puzzle piece:
The results are stored to the search.postids field (column)
as a comma-delimited string. Another field search.showposts is used as a lookup to determine whether the delimited values represent postids, or threadids....
...the actual "count" (# of matches) isn't saved into a field.
Who cares to have the actual postids later, when reporting?
(Many of them will change over time, anyway.)
the searchhistory should have a "count" field & search.php needs a small subroutine to eval the count & write to that field.