php cURL 或 file_get_content 对 Google Analytics 的影响
我想知道使用 php 加载外部页面对网站分析有何影响。如果 php 正在加载外部页面，而不是实际的浏览器，那么向 Google Analytics 报告的 JavaScript 是否会将页面加载注册为点击？
Im wondering what affect loading an external page with php has on a sites analytics. If php is loading an external page, and not an actual browser, will the javascript that reports back to google analytics register the page load as a hit?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
所获取页面中的任何 JavaScript 都不会运行，因此对分析没有影响。原因是获取的 HTML 页面永远不会在实际的浏览器中进行解析，因此不会执行任何 JavaScript。
Any JavaScript within the fetched page will not be run and therefore have no effect on analytics. The reason for this is that the fetched HTML page is never parsed in an actual browser, therefore, no JavaScript is executed.
Curl 不会自动下载 HTML 引用的 JavaScript 文件。因此，除非您明确下载 Google Analytics JavaScript 文件，否则 Google 不会检测到 Curl 命中。
Curl will not automatically download JavaScript files the HTML refers to. So unless you explicitly download the Google Analytics JavaScript file, Google won't detect the Curl hit.
Google 提供跟踪点击次数的非 JavaScript 方法。它适用于移动网站，但可以根据您的需要进行重新调整。
Google offers a non-JavaScript method of tracking hits. It's intended for mobile sites, but may be repurposable for your needs.
您误解了curl/file_get_contents 的工作原理。它们在服务器上执行，而不是在客户端浏览器上执行。就 Google 和任何普通用户而言，他们将看到这些调用的输出，而不是调用本身。
例如，
假设所有请求正常工作并且不发出如果服务器 A 和服务器 B 之间没有任何警告/错误并且没有网络故障，那么客户端绝对无法准确了解服务器 A 正在做什么。它可能正在发送本地文件。它可能正在执行本地脚本并发送其输出。它可能会将请求外包给印度的服务器，该服务器完成艰苦的工作，然后简单地声明其功劳，等等……
现在，您可以让客户端直接与服务器 B 对话。您可以让服务器 A 吐出一个 HTML 页面，其中包含指向服务器 B 的 iframe、图像标签、脚本标签、css 文件等。但这对客户端不再透明 - 您明确地告诉客户端“嘿，去那里看这个内容”。
You're misunderstanding how curl/file_get_contents work. They're executed on the server, not on the client browser. As far as Google and any regular user is concerned, they'll see the output of those calls, not the calls themselves.
e.g.
Assuming that all the requests work properly and don't issue any warnings/errors and there's no network glitches between server A and server B, then there is absolutely no way for the client to see exactly what server A's doing. It could be sending a local file. It could be executing a local script and send its output. It could be offshoring the request to a server in India which does the hard work and then simply claims the credit for it, etc...
Now, you CAN get the client to talk to server B directly. You could have server A spit out an HTML page that contains an iframe, image tag, script tag, css file, etc... that points to server B. But that's no longer transparent to the client - you're explicitly telling the client "hey, go over there for this content".