A product tour points at things and asks the customer to do them. A co-browse tour does them — it clicks through the interface and fills in fields while the person watches, with each click marked so it's clear what just happened.
It's the closest thing to sitting next to someone and taking the mouse, which is why it works for the cases where explaining has already failed.
You build it in the same editor as a product tour, on your own site, by performing the task yourself. What you do becomes what the tour does.
If the editor opens your page but never connects, the causes are the same as for a normal tour: the SDK isn't on that page, the page needs a login, or a Cross-Origin-Opener-Policy header is blocking it.
Use a co-browse tour when the doing is the hard part — a configuration with several screens, a setting buried three levels down, a form where the fields need particular values.
Use a normal tour when the point is for the customer to learn where things are. A co-browse tour completes the task; it doesn't necessarily teach anyone to repeat it.
The tour finds elements by how they're identified in your page. Interfaces that generate those identifiers freshly on each render — as some frameworks do — can leave a recorded step unable to find its target later.
Where you can, give the elements a tour depends on stable identifiers of your own. And re-run your co-browse tours after frontend changes, since a step that can't find its element simply stops.
One task per tour. A co-browse tour that does three unrelated things is impossible to offer at the right moment, and the moment is most of its value — it should run when someone is stuck on exactly that, not as a general introduction.
