It’s a complicated model but I’ll give you the easiest unblocking solution first, then I’ll do my best to add explanations that might help you understand the relevant pieces.
The easiest unblock
All of the standard playbook directories have XX-destroy playbooks like this one. Run them all, then run the model from the top again. This will essentially tear everything down and start again.
The general advice I have for modifications or additions to the model is that it supports ‘plugin’ customisation. You can find a guide to that here. Of course you’re free to change whatever you like in the standard model, but do so with the understanding that this is akin to modifying the source code of a tracker - once you’ve forked the logic it becomes hard for us to offer much support if you hit issues.
Most use cases can be done without forking though. For example you can configure the model to skip the update to the derived.page_views table, and instead use your own custom module to create a derived.page_views_custom instead.
Now for a couple of explanations of the detail:
It sounds like the table isn’t updating because despite deleting the derived tables, the manifests probably remained the same - the manifests determine what data is processed into the base module and through the model.
I double checked with the event_staged table in ‘scratch’ and it was empty. I believe this is why no data is processed for this run.
While you’re probably correct, note that the data in the scratch.events_staged normally gets dropped at the end of the model. If you have set cleanup_mode to “debug” or “trace” in the base module’s playbook, it doesn’t get dropped.