We need to know more about your application.
If you are doing something like counting revolutions, conditions may be changing quickly (bicycle wheel) or not (water wheel). Might need to be interrupt driven.
What about accuracy? If you miss a change you can still know the RPM. What if the value is wrong? If you are counting objects that pass, what if you miss one?
Are you concerned about the state of the magnet. For example is the window closed.
What do you want transmitted? The number of changes (since last report (not a good idea for unreliable bluetooth packets) or per unit of time) or the current state?
Regarding where to put a single state value in the packet, one idea is to use the least significant bit of a field you don’t care about. For example in format 03, byte holds hundredths of a degree centigrade with a maximum of 99. If you don’t care about that degree of resolution, jam a 1 (by ORing a 0x01) into that field to indicate presence (which 50% of the time will increase the temperature reported by .01°C) and clear the lowest bit by ANDing with 0xFE (which 50% of the time will decrease the temperature reported by .01°C.
Another more incompatible idea is to use the range over 99 (in the case of the temperature). For example if the sensor is present add 100. The result is that values over 99 are indicate presence, values 99 or less indicate not-present. This has the disadvantage of confusing existing receiver applications like RuuviStation and RuuviCollector, but may be easier to display with Grafana by simply dividing by 100.