A small suggestion. Not directly related to your article, but more from the perspective of how tracking for Views and Impressions itself could work. In theory what you’ve defined as Perceived in this article is actually an Impression. The definition for a View is most generally, ‘Did a user spend enough time on this element?’ (enough could be ‘X’ seconds spent on the element/screen, etc.)
You could start tracking events as a log of actions on the view — onScreen, offScreen, onScreen, offScreen (each with a unique timeStamp), as opposed to explicit events such as a view, impression, load, etc. and then stitch these together at your processing layer to derive the relevant metric — view, impression, etc. post facto. The most important aspect being, the definition of a view or an impression no longer resides on the client, but on the server side/processing layer, and the events you send out from the app start becoming generic. This will vastly help you keeping your code clean, and also ensure that your tracking needs are future proof.