The city portal analytics team treats page events as inputs for service design. Which source framing is correct?
Select an answer to reveal the explanation.
Short Explanation
Every click on the city website is a resident poking a machine. Those events are person-to-machine fuel for service-design analytics. They are not phone transcripts and not SCADA.
Full Explanation
Municipal web clickstreams are person-to-machine sources: humans interact with a portal that logs events. Analytics teams use them to improve service design and navigation for residents. Framing them as P2M clarifies privacy notices and pipeline design. They complement, rather than replace, other open-data feeds.
Calling clickstreams pure machine-to-machine with zero human involvement fails by concept: residents generate the clicks. Calling portal events person-to-person phone transcripts fails by concept: they are system interaction logs, not human-to-human calls. Calling page analytics a substitute for all open-data APIs fails by concept: clickstreams and open data serve different roles.
Exam caveat: Portal page events are P2M sources feeding applications—not M2M-only, P2P transcripts, or a full open-data replacement.
Operational check: Label portal analytics as P2M, update privacy notices for interaction logging, and keep open-data APIs in the inventory as separate external/shared sources. Document residual risk for civic operators and revisit after the next production change window. Confirm owners, SLAs, and rollback criteria in the runbook before go-live. Record the decision in the architecture decision log for auditors.