Ah! I can relate to your frustration with this topic.
Consider the ethernet frame format. The 802.1q tag is a 4 bytes long and is inserted by the network switch between the SA and type/len fields of the ethernet frame.
Private VLANs are characterized by a single primary VLAN and secondary VLANs ("community" and "isolated").
When a switchport is configured as a pvlan host port, say of the "community" type, all frames that ingress the network are tagged with the community vlan-id. Note that during egress to the host, the switch removes the tag.
The key concept is the upstream filtering capability provided by private vlans. Frames from "community" ports are tagged with their secondary vlan-id upon ingress, and they are only forwarded to other ports in the same community OR promiscuous ports. It gets stricter with "isolated" ports where frames are only forwarded upstream to promiscuous ports. Note that promiscuous ports tag with primary vlan-id.
Lastly, note that promiscuous ports specify a mapping that encompasses the primary VLAN and a list of secondary VLANs. This aspect controls which secondary VLANs are allowed to talk to the host connected to the promiscous port.
For example, you may have a network where users need access to web-servers and email, but guests are only allowed access to web-servers. Here, you can achieve your objectives by configuring a community VLAN each for employees and guests, web-server promiscuous host ports that map the primary to both secondary VLANs, and finally email promiscuous host ports that map the primary to only the employee community.
Private VLANs work in VTP transparent mode only. As long as they are created consistently, and trunked across switches, they can be effective over a multi-switch network. Each switch will enforce the same ingress vlan-id tagging and forwarding logic for upstream traffic.