Technically, that part of the footprints feature doesn't need XPM to run. However, there are at least two reasons why you should only do it on a staging site with XPM:
- The cookie is set by XPM (and cookies are only valid for the current site). Without XPM, you would need to set these footprint cookies yourself.
- Allowing the overwriting of claims is actually a security risk. You are essentially allowing anyone to write data to memory on your website. Although that's also a risk on a staging site, it's not as likely that one of your employees will abuse it (and if they do, they're much easier to track down). Although any would-be attacker would need to know a lot about this feature and how to write the cookie, it still seems like a risk you don't want to take on your live production environment.
Ideally, users are able to trust that if the Promotion fires on the staging site, it also fires on the live site. But I can understand the urge to validate that.
You could consider creating a test page that allows you to tweak the claims. That way, it can tightly control what data gets set on what claims (i.e. don't allow any arbitrary input from the client) - thus minimizing the security risk while still allowing you to verify that the Promotions work on the live site.
However, even a testing page is no guarantee that real visitors see what you want. If the claims are not set anywhere else on the website, no visitor will see your Promotions anyhow. So your test page would actually lead you to believe everything is working, when it fact it is not.
In the end, it's possible that only careful examination of the log files will tell you if there is a problem with your triggers and thus your Promotions. I would say that is up to the developers/ops guys to ensure -- and your editors should just be able to trust that the live site has the same triggers as the staging does, and so what they see on staging will also apply on the live website.
