The code holds an address, not a document
A QR code stores a few thousand characters at the absolute maximum, and the density rises so fast with length that a realistic printed code holds a few hundred comfortably. A single-page PDF is hundreds of kilobytes. There is no version of this where the document is inside the pattern.
So “PDF QR code” always means: the file sits on a server, and the code is its address. Every problem people hit with these is a hosting problem wearing a QR costume.
Where to put the file
On something you control and expect to keep paying for. Your own site, or storage attached to it, is the safe answer.
The common mistake is a share link from personal cloud storage. Those links expire, sometimes ask for a sign-in the scanner does not have, and break when the file is dragged into a different folder six months later by someone who has never heard of the poster. A printed code has no way to tell anyone it broke; the failure is silent and lands on a customer.
Keeping it replaceable
The whole reason to think about this is that PDFs change. Menus get new prices, manuals get new revisions, brochures get a new logo. There are exactly two ways to update the document behind a printed code.
Overwrite at the same URL. Keep the filename identical and replace the contents. This works, and it fails the first time somebody uploads menu-v2.pdf instead of overwriting menu.pdf, which is roughly always. It also requires whoever updates the file in future to know that the filename is load-bearing, and nothing in the filename says so.
Point a dynamic code at it. The printed pattern encodes a redirect you own, and the file it points to is a setting. Upload the new PDF under any name, change where the code points, done. It also survives moving the file to different hosting entirely, which the first approach does not.
What the phone actually does with it
Current iOS and Android browsers render PDFs inline rather than downloading them, so in the good case the person scans and the document appears. That good case assumes the file arrives.
The usual failure is size. A brochure exported at print resolution can be 20MB, which is fine over office WiFi and hopeless for someone standing in a shop on two bars of signal. They will close it before it loads and you will never know. Re-exporting at screen resolution routinely cuts that by an order of magnitude with no visible difference on a phone.
Worth asking whether it should be a PDF at all. For a menu or a price list, a web page reflows to the screen, is searchable, and does not need pinch-to-zoom. Keep the PDF when the layout is the point: forms, certificates, manuals with diagrams, anything people will print or file.
What you can measure
With a static code pointing straight at a file, nothing, unless your file host reports downloads. With a dynamic code, the redirect is a request that can be counted, so you get scans with device and approximate location.
That is scans, not reads. Whether the document was opened and studied or closed after two seconds happens inside a PDF viewer, out of reach of anything on our side. Treat the number as interest, not comprehension.