1
00:00:00,000 --> 00:00:03,760
Welcome to the deep dive, the knowledge shortcut you need to master a mountain of

2
00:00:03,760 --> 00:00:04,880
sources quickly.

3
00:00:04,880 --> 00:00:09,120
Today we are opening a really fascinating window into internet history, the server

4
00:00:09,120 --> 00:00:10,480
log. Before all

5
00:00:10,480 --> 00:00:15,000
the modern JavaScript heavy tracking became the norm, all the intelligence about

6
00:00:15,000 --> 00:00:15,760
who was visiting

7
00:00:15,760 --> 00:00:20,050
your site and how well it was hidden right there in these cryptic files. We are

8
00:00:20,050 --> 00:00:21,440
diving deep into

9
00:00:21,440 --> 00:00:24,880
the technology that helped make sense of it all. Now, if you're new to web

10
00:00:24,880 --> 00:00:26,240
operations, maybe think

11
00:00:26,240 --> 00:00:31,140
of a server log like this. It's the quiet, meticulous security guard who writes

12
00:00:31,140 --> 00:00:31,920
down every

13
00:00:31,920 --> 00:00:36,180
single interaction at the door, every request, every failure, every successful

14
00:00:36,180 --> 00:00:36,960
handshake.

15
00:00:36,960 --> 00:00:40,900
It's dense raw data but it's full of gold. Before we unlock this data though, we

16
00:00:40,900 --> 00:00:41,520
want to thank the

17
00:00:41,520 --> 00:00:45,580
supporter of this deep dive, SafeServer. They specialize in hosting software,

18
00:00:45,580 --> 00:00:45,840
helping you

19
00:00:45,840 --> 00:00:49,370
manage tools just like the one we are discussing today and supporting your digital

20
00:00:49,370 --> 00:00:50,320
transformation.

21
00:00:50,320 --> 00:00:54,990
You can find more information at www.saveserver.de. Okay, so our mission today is

22
00:00:54,990 --> 00:00:56,000
really to unpack

23
00:00:56,000 --> 00:01:01,390
AWStats. That stands for Advanced Web Statistics. This tool is, well, it's

24
00:01:01,390 --> 00:01:02,320
foundational because it

25
00:01:02,320 --> 00:01:06,750
was free, powerful, and it genuinely made web analytics accessible, even for

26
00:01:06,750 --> 00:01:07,680
beginners back

27
00:01:07,680 --> 00:01:12,000
then. It's the thing that took that raw, pretty technical server data and turned it

28
00:01:12,000 --> 00:01:13,120
into graphical,

29
00:01:13,120 --> 00:01:18,800
actionable intelligence. Fundamentally, AWStats is a powerful log analyzer. It was

30
00:01:18,800 --> 00:01:19,440
distributed

31
00:01:19,440 --> 00:01:24,420
under the GNU general public license, the GPL, and that license detail is actually

32
00:01:24,420 --> 00:01:24,960
key because

33
00:01:24,960 --> 00:01:29,360
it means the software was always free, always community-driven. It didn't just

34
00:01:29,360 --> 00:01:30,080
analyze web

35
00:01:30,080 --> 00:01:34,200
servers either. It could generate advanced stats for streaming services, FTP, even

36
00:01:34,200 --> 00:01:35,040
mail servers,

37
00:01:35,040 --> 00:01:38,800
and deliver all that rich data visually. Right, so let's start with the basics

38
00:01:38,800 --> 00:01:39,280
maybe for those

39
00:01:39,280 --> 00:01:42,800
who haven't actually touched a server log before. If the log is just this massive

40
00:01:42,800 --> 00:01:43,440
text file of

41
00:01:43,440 --> 00:01:47,990
transactions, how did AWStats work its magic? What is a log file analyzer,

42
00:01:47,990 --> 00:01:49,600
practically speaking?

43
00:01:49,600 --> 00:01:55,200
Think of it as a translator. Log data is messy, right? Timestamps, IP addresses,

44
00:01:55,200 --> 00:02:00,080
requested files, status codes. It's almost impossible to read manually and get any

45
00:02:00,080 --> 00:02:00,400
real

46
00:02:00,400 --> 00:02:06,580
insight. AWStats takes that whole stream and, in its own words, transforms it into

47
00:02:06,580 --> 00:02:07,040
understandable

48
00:02:07,040 --> 00:02:12,080
reports using few graphical web pages. Basically, it turns lines of code into bar

49
00:02:12,080 --> 00:02:13,040
charts and pie

50
00:02:13,040 --> 00:02:16,400
graphs, makes it visual. And what's fascinating here, reading through the sources,

51
00:02:16,400 --> 00:02:16,880
is just how

52
00:02:16,880 --> 00:02:21,360
compatible it was. This wasn't some niche script just for certain platforms, was it?

53
00:02:21,360 --> 00:02:21,920
Not at all.

54
00:02:21,920 --> 00:02:25,420
It was, you could say, an equal opportunity analyzer. It could handle logs from

55
00:02:25,420 --> 00:02:26,000
pretty much

56
00:02:26,000 --> 00:02:30,240
every major server tool available at the time. We're talking Apache logs, the NCSA

57
00:02:30,240 --> 00:02:30,800
combined or

58
00:02:30,800 --> 00:02:36,320
common formats, ISA logs using the W3C format Webstar, plus logs from specialized

59
00:02:36,320 --> 00:02:37,200
proxy, WAP,

60
00:02:37,200 --> 00:02:41,360
and streaming servers. That kind of breadth, that compatibility, it's really a hallmark

61
00:02:41,360 --> 00:02:41,840
of truly

62
00:02:41,840 --> 00:02:45,870
foundational software. And how did this, you know, relatively small free tool

63
00:02:45,870 --> 00:02:46,640
handle all the heavy

64
00:02:46,640 --> 00:02:50,270
lifting? Running a log analyzer on big servers sounds like it could be pretty

65
00:02:50,270 --> 00:02:51,360
intensive. Yeah,

66
00:02:51,360 --> 00:02:55,040
that's where some clever engineering comes in. AWStats was designed to be

67
00:02:55,040 --> 00:02:56,800
lightweight and flexible.

68
00:02:56,800 --> 00:03:03,620
It was primarily written in Perl, which, okay, itself requires Perl 5.000003 or

69
00:03:03,620 --> 00:03:04,160
higher for the

70
00:03:04,160 --> 00:03:07,300
more modern versions. And you could run it right from the command line, or you

71
00:03:07,300 --> 00:03:08,080
could execute it

72
00:03:08,080 --> 00:03:12,370
dynamically as a CGI script. That flexibility was key. Hold on. If it's running off

73
00:03:12,370 --> 00:03:13,200
a lightweight

74
00:03:13,200 --> 00:03:18,320
language like Perl, how did it possibly manage enterprise scale log files? I mean,

75
00:03:18,320 --> 00:03:18,800
we could be

76
00:03:18,800 --> 00:03:23,260
talking about logs of practically unlimited size on busy servers. Wouldn't that

77
00:03:23,260 --> 00:03:24,400
just grind the system

78
00:03:24,400 --> 00:03:27,470
to a halt? That's an excellent point, and it really hits on the core challenge of

79
00:03:27,470 --> 00:03:28,960
early log analysis.

80
00:03:28,960 --> 00:03:33,790
To process these potentially massive log files quickly and often, it uses something

81
00:03:33,790 --> 00:03:34,080
called a

82
00:03:34,080 --> 00:03:38,000
partial information file. So instead of recalculating every single metric from the

83
00:03:38,000 --> 00:03:38,960
raw log every single

84
00:03:38,960 --> 00:03:42,880
time, which would take hours, it stores intermediate data in that partial file.

85
00:03:42,880 --> 00:03:43,680
This means subsequent

86
00:03:43,680 --> 00:03:48,480
runs are incredibly fast. It saves a ton of server resources. Ah, okay. So it sort

87
00:03:48,480 --> 00:03:49,600
of pre-digested the

88
00:03:49,600 --> 00:03:54,030
information, making the updates almost instantaneous even if the raw log file kept

89
00:03:54,030 --> 00:03:54,880
getting bigger and

90
00:03:54,880 --> 00:03:58,440
bigger. That's pretty clever resource management. Precisely. And that efficiency

91
00:03:58,440 --> 00:03:59,200
was absolutely

92
00:03:59,200 --> 00:04:03,680
crucial because it meant it could handle logs that were split across multiple files

93
00:04:03,680 --> 00:04:04,640
or even logs that

94
00:04:04,640 --> 00:04:08,720
weren't perfectly sorted, which believe me was a common headache when you're

95
00:04:08,720 --> 00:04:09,920
dealing with large

96
00:04:09,920 --> 00:04:14,820
load-balanced systems. And for the newcomer, the setup was famously simple. The

97
00:04:14,820 --> 00:04:15,600
documentation

98
00:04:15,600 --> 00:04:21,160
literally said just one configuration file to edit. That low barrier to entry for

99
00:04:21,160 --> 00:04:21,440
something

100
00:04:21,440 --> 00:04:25,920
so powerful, that's a big reason why it became so popular globally. That simplicity

101
00:04:25,920 --> 00:04:27,120
is remarkable.

102
00:04:27,120 --> 00:04:31,120
But here's where the data gets really juicy, I think. Most people might think of

103
00:04:31,120 --> 00:04:31,840
server logs

104
00:04:31,840 --> 00:04:36,680
as just basic traffic counters, page views, maybe hits. But AWStats extracted this

105
00:04:36,680 --> 00:04:37,760
surprising level

106
00:04:37,760 --> 00:04:42,800
of detail that, well, even modern tag-based analytics sometimes overlooks. Let's

107
00:04:42,800 --> 00:04:43,120
get into

108
00:04:43,120 --> 00:04:47,590
the specifics of what this tool was revealing. Okay, so if we start with traffic

109
00:04:47,590 --> 00:04:48,240
and timing,

110
00:04:48,240 --> 00:04:51,920
it definitely gave you the essentials. Number of visits, unique visitors, average

111
00:04:51,920 --> 00:04:52,960
visit duration,

112
00:04:52,960 --> 00:04:57,620
standard stuff. But it synthesized this data to provide genuine business

113
00:04:57,620 --> 00:04:58,960
intelligence. It showed

114
00:04:58,960 --> 00:05:05,390
your site's rush hours and rush days. It detailed pages, hits, kilobytes

115
00:05:05,390 --> 00:05:07,200
transferred for each hour

116
00:05:07,200 --> 00:05:10,560
of the day or each day of the week. That tells you exactly when to schedule server

117
00:05:10,560 --> 00:05:10,960
maintenance,

118
00:05:10,960 --> 00:05:14,940
right? Or maybe when to launch your most important content. It shifts you from just

119
00:05:14,940 --> 00:05:15,520
counting things

120
00:05:15,520 --> 00:05:20,750
to actually planning. Exactly. But the granularity, it deepens significantly when

121
00:05:20,750 --> 00:05:21,840
we look at visitor

122
00:05:21,840 --> 00:05:27,600
identity and technology. This is where AWStats really, really shined in that fragmented

123
00:05:27,600 --> 00:05:28,000
early

124
00:05:28,000 --> 00:05:33,970
internet era. Using GOAP detection, it could automatically identify 269 domains in

125
00:05:33,970 --> 00:05:34,720
countries.

126
00:05:34,720 --> 00:05:38,290
And maybe more importantly for web developers back then, it identified the

127
00:05:38,290 --> 00:05:39,200
technical stack of

128
00:05:39,200 --> 00:05:43,290
the visitor. We're talking detecting 35 different operating systems and a core of

129
00:05:43,290 --> 00:05:44,240
97 different

130
00:05:44,240 --> 00:05:49,180
browsers. 97 browsers? Wow. That sounds like a testing nightmare for developers. It

131
00:05:49,180 --> 00:05:49,520
was a

132
00:05:49,520 --> 00:05:54,040
fragmentation nightmare, which is exactly why this tool was so critical. Just the

133
00:05:54,040 --> 00:05:54,720
ability to

134
00:05:54,720 --> 00:05:59,570
automatically identify that fragmentation, that was power. And furthermore, if you

135
00:05:59,570 --> 00:06:00,320
use the specific

136
00:06:00,320 --> 00:06:05,200
browser library it offered, that number jumped to over 450 detected browsers,

137
00:06:05,200 --> 00:06:06,560
including various

138
00:06:06,560 --> 00:06:11,000
phone and mobile clients. That level of detail. It's something modern analytics

139
00:06:11,000 --> 00:06:12,240
often just aggregates

140
00:06:12,240 --> 00:06:16,340
away, you know. That kind of specificity must have been absolutely vital for making

141
00:06:16,340 --> 00:06:16,880
decisions

142
00:06:16,880 --> 00:06:21,140
about feature support, especially back in the early 2000s when tech wasn't nearly

143
00:06:21,140 --> 00:06:22,160
as standardized as

144
00:06:22,160 --> 00:06:28,090
it is now. Absolutely. And that brings us neatly to the technical insights. This is

145
00:06:28,090 --> 00:06:28,800
maybe the key

146
00:06:28,800 --> 00:06:33,040
insight for understanding historical web development challenges. AWS stats could

147
00:06:33,040 --> 00:06:34,080
report the ratio of

148
00:06:34,080 --> 00:06:39,220
visitors whose browsers supported critical, often non-standard features like Java,

149
00:06:39,220 --> 00:06:39,840
Flash,

150
00:06:39,840 --> 00:06:46,000
Real G2, QuickTime, WMA, even PDF readers. Knowing this dictated huge development

151
00:06:46,000 --> 00:06:46,640
decisions. I mean,

152
00:06:46,640 --> 00:06:50,560
if only 10% of your audience supported Flash, you knew building your main

153
00:06:50,560 --> 00:06:51,600
navigation in Flash

154
00:06:51,600 --> 00:06:55,040
would basically kill your traffic. This wasn't just a nice-to-have feature. This

155
00:06:55,040 --> 00:06:55,760
was like a

156
00:06:55,760 --> 00:06:59,600
fundamental operational requirement. It told developers whether their audience

157
00:06:59,600 --> 00:06:59,920
could even

158
00:06:59,920 --> 00:07:03,550
consume the content they just spent weeks building. That's a fascinating look at

159
00:07:03,550 --> 00:07:03,600
the

160
00:07:03,600 --> 00:07:07,590
historical constraints of the web, really put things in perspective. Moving beyond

161
00:07:07,590 --> 00:07:08,080
technical

162
00:07:08,080 --> 00:07:11,680
capabilities, what did AWStats tell us about why people found the site in the first

163
00:07:11,680 --> 00:07:12,160
place,

164
00:07:12,160 --> 00:07:16,720
the marketing side? Right, that falls under marketing and search insights. Because

165
00:07:16,720 --> 00:07:16,800
the

166
00:07:16,800 --> 00:07:21,650
log file records the referrer, basically, where the visitor came from, ADStats

167
00:07:21,650 --> 00:07:22,400
could reverse

168
00:07:22,400 --> 00:07:26,400
engineer the search process. It detected search engines, key phrases, and keywords

169
00:07:26,400 --> 00:07:26,960
used to find

170
00:07:26,960 --> 00:07:31,890
the site. And get this, it recognized 115 of the most famous search engines at the

171
00:07:31,890 --> 00:07:32,480
time.

172
00:07:32,480 --> 00:07:36,640
115 search engines. That truly is a historical snapshot, isn't it? You're talking

173
00:07:36,640 --> 00:07:37,120
about a world

174
00:07:37,120 --> 00:07:42,800
where Google was just one player among many alongside giants like Yahoo and the venerable

175
00:07:42,800 --> 00:07:47,760
AltaVista. It captures that moment in time perfectly. And then we have the security

176
00:07:47,760 --> 00:07:47,840
and

177
00:07:47,840 --> 00:07:51,680
maintenance data. This was equally critical for system administrators. It tracked

178
00:07:51,680 --> 00:07:52,720
visits by

179
00:07:52,720 --> 00:07:58,640
319 different automated robots or bots, helping admins separate human traffic from

180
00:07:58,640 --> 00:07:59,120
crawlers,

181
00:07:59,120 --> 00:08:03,680
which is crucial for accurate stats. And really importantly, it detected five

182
00:08:03,680 --> 00:08:04,800
families of worm

183
00:08:04,800 --> 00:08:09,970
attacks, giving you real time, well, almost real time security warnings right from

184
00:08:09,970 --> 00:08:10,880
your logs.

185
00:08:10,880 --> 00:08:17,680
Plus it reported all the HTTP errors like the classic page not found, 404 errors.

186
00:08:17,680 --> 00:08:18,080
And for

187
00:08:18,080 --> 00:08:21,870
maintenance, this was great. It showed the last refer for that bad link. So you

188
00:08:21,870 --> 00:08:22,640
could immediately

189
00:08:22,640 --> 00:08:27,040
go fix broad internal links or, you know, contact an external site that was sending

190
00:08:27,040 --> 00:08:30,910
traffic to a dead page on your site. That's incredibly powerful diagnostics

191
00:08:30,910 --> 00:08:31,280
straight from

192
00:08:31,280 --> 00:08:35,490
the log file. And I love the final little quirk our sources mentioned here. It

193
00:08:35,490 --> 00:08:36,000
actually tracked

194
00:08:36,000 --> 00:08:41,040
the number of times the site was added to favorites bookmarks. That's pure old

195
00:08:41,040 --> 00:08:41,360
school

196
00:08:41,360 --> 00:08:44,790
engagement data, isn't it? Extracted directly from the server transaction. Yeah, it

197
00:08:44,790 --> 00:08:45,360
just shows the

198
00:08:45,360 --> 00:08:48,390
breadth of metadata that was actually available in those raw transactions if you

199
00:08:48,390 --> 00:08:48,960
had the right

200
00:08:48,960 --> 00:08:53,770
tool to pull it out. Okay, so we've established that AWS stats was powerful, it was

201
00:08:53,770 --> 00:08:54,160
free,

202
00:08:54,160 --> 00:08:58,800
and it was incredibly detailed for what was essentially a single config file per

203
00:08:58,800 --> 00:08:59,760
all script.

204
00:08:59,760 --> 00:09:04,160
This obviously made it super popular with individual users, site owners. But what

205
00:09:04,160 --> 00:09:04,400
about

206
00:09:04,400 --> 00:09:09,840
the pros? Like web hosting providers managing hundreds, maybe thousands of sites.

207
00:09:09,840 --> 00:09:10,240
Did this

208
00:09:10,240 --> 00:09:14,880
simple tool scale up to meet those kinds of enterprise demands? It absolutely did.

209
00:09:14,880 --> 00:09:14,880
The

210
00:09:14,880 --> 00:09:19,040
tool's flexibility really made it ideal for providers. Crucially, it supported

211
00:09:19,040 --> 00:09:19,680
multi-named

212
00:09:19,680 --> 00:09:24,640
websites or what we usually call virtual servers or virtual hosts. This meant a

213
00:09:24,640 --> 00:09:25,200
hosting company

214
00:09:25,200 --> 00:09:29,810
could run just one instance of AWS stats and efficiently analyze the separate log

215
00:09:29,810 --> 00:09:30,240
files

216
00:09:30,240 --> 00:09:34,900
for dozens, even hundreds of their clients. The output flexibility was also key for

217
00:09:34,900 --> 00:09:35,360
integration

218
00:09:35,360 --> 00:09:39,830
purposes. Reports could be generated dynamically via CGI, maybe on demand, or you

219
00:09:39,830 --> 00:09:40,480
could generate

220
00:09:40,480 --> 00:09:45,110
static HTML or XHTML pages. Perfect for just dropping into a client's control panel

221
00:09:45,110 --> 00:09:45,920
or portal.

222
00:09:46,480 --> 00:09:50,960
Our sources even note that experimental PDF export was possible at some point.

223
00:09:50,960 --> 00:09:54,320
And given that this tool was digging around in potentially sensitive server data,

224
00:09:54,320 --> 00:09:58,800
I assume security and maybe extensibility were thought about, built in.

225
00:09:58,800 --> 00:10:03,040
Yes, definitely. Security was baked in. Notably, it included protection against

226
00:10:03,040 --> 00:10:04,080
cross-site scripting

227
00:10:04,080 --> 00:10:08,610
attacks, XSS attacks, that was important. And its extensibility was actually

228
00:10:08,610 --> 00:10:09,920
massive. It supported

229
00:10:09,920 --> 00:10:14,630
numerous options, filters, and plugins. Things like reverse DNS lookup to turn IP

230
00:10:14,630 --> 00:10:15,520
addresses into

231
00:10:15,520 --> 00:10:19,600
host names. And for developers who wanted to manipulate the analysis data outside

232
00:10:19,600 --> 00:10:20,080
the tool

233
00:10:20,080 --> 00:10:24,080
itself, it offered the ability to store the results in XML format, which you could

234
00:10:24,080 --> 00:10:24,960
then process with

235
00:10:24,960 --> 00:10:29,780
XSLT or other tools. It truly provided both the raw insights and the tools to

236
00:10:29,780 --> 00:10:31,120
customize how you use

237
00:10:31,120 --> 00:10:34,860
them. So we have this really foundational, highly capable, free tool that was

238
00:10:34,860 --> 00:10:35,840
basically the backbone

239
00:10:35,840 --> 00:10:39,660
of web analytics for many years. But here's the inevitable question, the status

240
00:10:39,660 --> 00:10:40,240
update.

241
00:10:40,240 --> 00:10:43,680
What is the health of the AWS Stats project today? Where does it stand?

242
00:10:43,680 --> 00:10:47,360
Right. And here is the critical status update for anyone still using it or

243
00:10:47,360 --> 00:10:48,400
considering it.

244
00:10:48,400 --> 00:10:53,600
AWS Stats is now essentially transitioning into a legacy phase. The original author,

245
00:10:53,600 --> 00:10:58,880
Laurent de Steyer, who interestingly is also the project leader of Dolly Bar ERPCRM,

246
00:10:58,880 --> 00:11:03,360
he's no longer developing new versions himself. Version 8.0, which was actually

247
00:11:03,360 --> 00:11:04,240
released back on

248
00:11:04,240 --> 00:11:09,440
August 26, 2025, is planned to be the last version released by the original author.

249
00:11:09,440 --> 00:11:10,160
So this means that

250
00:11:10,160 --> 00:11:14,590
future maintenance, any bug fixes, any new feature development, it's all going to

251
00:11:14,590 --> 00:11:15,600
rely entirely on

252
00:11:15,600 --> 00:11:19,620
the community stepping up. It's shifting toward that classic open source community

253
00:11:19,620 --> 00:11:20,800
support model now.

254
00:11:20,800 --> 00:11:25,100
Okay, so for our listeners who really rely on this kind of powerful log-based

255
00:11:25,100 --> 00:11:25,760
analysis

256
00:11:25,760 --> 00:11:29,090
and maybe especially value data ownership, you know, the ability to keep their

257
00:11:29,090 --> 00:11:30,240
server data local

258
00:11:30,240 --> 00:11:33,590
under their own control, what's the recommended migration path now that the

259
00:11:33,590 --> 00:11:34,320
original development

260
00:11:34,320 --> 00:11:38,590
is wrapping up? Well, the clearest and probably most recommended migration path,

261
00:11:38,590 --> 00:11:39,040
especially for

262
00:11:39,040 --> 00:11:43,680
those prioritizing open source principles and data control, is Matomo. Specifically,

263
00:11:43,680 --> 00:11:44,080
they should look

264
00:11:44,080 --> 00:11:48,010
at Matomo log analytics. This tool really maintains that core principle of

265
00:11:48,010 --> 00:11:49,760
analyzing raw server logs.

266
00:11:49,760 --> 00:11:54,030
It avoids client-side tracking tags, just like AWStats, and it offers a pretty

267
00:11:54,030 --> 00:11:54,880
smooth path for

268
00:11:54,880 --> 00:11:58,230
users looking to transition, potentially bringing their historical data and

269
00:11:58,230 --> 00:11:59,360
analysis methods over

270
00:11:59,360 --> 00:12:04,220
from AWStats. Wow. Okay, we've covered a truly remarkable piece of internet

271
00:12:04,220 --> 00:12:05,840
infrastructure today.

272
00:12:05,840 --> 00:12:12,550
We explored how a relatively simple single config file Perl script called AWStats

273
00:12:12,550 --> 00:12:13,680
managed to transform

274
00:12:13,680 --> 00:12:18,070
these cryptic server logs into clear graphical intelligence. It provided this just

275
00:12:18,070 --> 00:12:18,800
unparalleled

276
00:12:18,800 --> 00:12:22,650
detail for its time, tracking everything from, you know, five families of worm

277
00:12:22,650 --> 00:12:23,440
attacks to the

278
00:12:23,440 --> 00:12:27,520
specific browser capabilities that literally dictated early web design decisions,

279
00:12:27,520 --> 00:12:27,760
all while

280
00:12:27,760 --> 00:12:31,990
being free and open source. And here is the final provocative thought we want to

281
00:12:31,990 --> 00:12:33,200
leave you with today.

282
00:12:33,200 --> 00:12:39,360
AWStats proved years ago that you could extract incredible, really granular data

283
00:12:39,360 --> 00:12:40,000
about user

284
00:12:40,000 --> 00:12:44,090
behavior, their OS, their browser capabilities, their geography, all from the

285
00:12:44,090 --> 00:12:45,600
server-side log file.

286
00:12:45,600 --> 00:12:50,710
This required no third-party JavaScript, no cookies, no client-side tracking tags

287
00:12:50,710 --> 00:12:51,680
whatsoever.

288
00:12:51,680 --> 00:12:55,760
So if all that depth of data was sitting right there in the log file the whole time,

289
00:12:55,760 --> 00:13:00,240
what valuable metrics are we potentially missing today by relying so heavily, maybe

290
00:13:00,240 --> 00:13:00,880
solely,

291
00:13:00,880 --> 00:13:05,070
on JavaScript-based analytics, analytics that are prone to ad blockers, network

292
00:13:05,070 --> 00:13:05,520
issues,

293
00:13:05,520 --> 00:13:10,080
and increasing privacy limitations? It really makes you wonder how much visibility,

294
00:13:10,080 --> 00:13:14,400
maybe even control, we've handed over in the process. A fascinating question to ponder

295
00:13:14,400 --> 00:13:15,280
indeed.

296
00:13:15,280 --> 00:13:18,580
Thank you for joining us for this deep dive. We want to extend one final thanks to

297
00:13:18,580 --> 00:13:19,200
our sponsor,

298
00:13:19,200 --> 00:13:22,070
SafeServer, for supporting this exploration and for assisting with digital

299
00:13:22,070 --> 00:13:22,880
transformation.

300
00:13:22,880 --> 00:13:27,950
You can find out more at www.sacesserver.de. Join us next time for another deep

301
00:13:27,950 --> 00:13:28,480
dive into what you