Including webpage URL in VoiceFlow chatbot conversation logs

I want to capture the current page URL where users interact with my VoiceFlow chatbot and include it in the conversation transcripts. This would help me track which pages generate the most questions from users.

I attempted to pass the URL through the launch event payload, but it’s not working as expected:

(function(doc, scriptTag) {
  var widget = doc.createElement(scriptTag), existing = doc.getElementsByTagName(scriptTag)[0];
  widget.onload = function() {
    window.voiceflow.chat.load({
      verify: { projectID: 'YOUR_PROJECT_ID_HERE' },
      url: 'https://general-runtime.voiceflow.com',
      versionID: 'production',
      launch: {
        event: {
            type: "launch",
            payload: {
            page_url: window.location.href
            }
        }
        },
        autostart: false
    });
  }
  widget.src = "https://cdn.voiceflow.com/widget/bundle.mjs";
  widget.type = "text/javascript";
  existing.parentNode.insertBefore(widget, existing);
})(document, 'script');

I also tried retrieving the URL data like this:

if (previous_event) {
  page_url = previous_event.payload.page_url
} else {
  page_url = "unknown"
}

The issue is that previous_event appears to be undefined, and I’m not sure how to properly store this URL information in the transcript logs. Has anyone successfully implemented URL tracking in VoiceFlow transcripts?

use the request step in voiceflow to grab window.location.href straight from the frontend - dont bother with launch payload. store it as a variable and it’ll show up in your transcripts automatically. way better than using events.

In my experience, capturing the current page URL before the VoiceFlow widget loads has proven effective. I suggest defining a global variable such as window.currentPageUrl = window.location.href at the beginning of your script. This allows for easier retrieval later through a custom action or an API step, making it more dependable than relying on launch events. By storing this data in a session variable early in the conversation, it will persist throughout the session and be recorded in transcript logs, giving you valuable insight into user behavior across different pages.

you could also use custom actions with javascript to grab the url while the convo’s happening. set up a custom action that runs return {url: window.location.href} and call it whenever you need the page data. this way you dont deal with launch timing headaches n can catch url changes if users navigate during the chat.

The launch payload approach works, but you need to access it through the correct VoiceFlow context. Instead of using previous_event, grab the launch data through session variables in your flow. When you pass page_url in the launch payload, it becomes available in the initial interaction context. You should create a variable in VoiceFlow called page_url and map it to the payload data at the start of your conversation flow. This will capture the URL in the session and ensure it shows up in your transcript logs. Be sure to handle the payload extraction in your flow’s first step right after launch.

Had this exact issue a few months ago tracking user behavior on our product pages. The launch event payload is a pain because of timing issues.

I fixed it with postMessage to send URL data after the widget loads:

window.voiceflow.chat.load({
  verify: { projectID: 'YOUR_PROJECT_ID_HERE' },
  url: 'https://general-runtime.voiceflow.com',
  versionID: 'production',
  autostart: false
});

// Send URL after widget is ready
window.voiceflow.chat.interact({
  type: 'text',
  payload: {
    message: '',
    data: {
      page_url: window.location.href
    }
  }
});

In your VoiceFlow, add a capture step at the start. Create a current_page variable and map it to the incoming data.

Send the URL as part of the first interaction instead of embedding it in launch config. Gets logged properly in transcripts and you can reference it throughout the conversation.

Been using this for months - works perfectly for tracking which pages generate the most support questions.