We have a an ecommerce platform where we need to store user session data in a database such as products viewed and products liked. When is the right time to call an API to store this data?
I don't want to call an API every time they open a new product.
I've experimented with DOM methods such as visibilitychange but on our website, every product is opened in a new tab so it's not ideal.
Should we use some background scripts such as service workers?
Related
I’m wondering if there’s a possibility to open a Bank Application on your phone, from browser.
Use case - our team has a web app, which stores our ordered lunches and its’ prices.
I would like to implement a feature - you click on a link, it opens up bank application, puts in IBAN, variable symbol, amount.
As I read in the Google documentation “all contexts expire after 20 minutes of becoming active” (https://cloud.google.com/dialogflow/docs/contexts-input-output). What I was wondering is if there is a way to extend this limit. For example, if I store an mp3 playlist in my context so that I can play next audio at the end of the current one, if the duration of the current mp3 exceeds 20 minutes I lose the context and any information on the next mp3.
You need to setup 2 things:
Your own webhook server.
A DB of your preference (I chose MongoDB) to store user data identifyied by an unique chat id, and it can be retrieved diferently from each platform that you integrate your chatbot with.
For example: on facebook you can use the userID of the user that is having a conversation with your bot as uniqueID, on twilio you can use the phonenumber and on your own chat UI for web you can stablish your own ID (usually a timestamp) as a parameter of the request you send to Dialogflow and store it on the localStorage of the client browser. So the next time the user chats with your bot within that same browser, you can get his data by using this uniqueID.
For facebook you can get the userid by using:
agent.originalRequest.payload.data.sender.id
For twilio:
agent.originalRequest.payload.data.From
For web (it depends of the variable that you send to the API)
agent.originalRequest.payload.data.{variable}
Using this uniqueID you can create your own DB registry for each user, get, retrieve or store data and make your contexts stay forever.
PS: Let me know If I was clear, its 4:34 AM lol, I can comment on this to clear any doubts.
Peace!
Does IBM Domino track the last login date for web users(UserName/Password and internet certificate)? I know the access logs contains this information but wanted to know if there may be something built into Domino (maybe in Address Book). Trying to come up with a method to disable web accounts that have not accessed a domino server in a specified time period.
Thanks,
Kev
The User Activity area in the Database Properties picks up from the log.nsf, which is where this information is stored. But, typically, the log.nsf will only have a few days' worth of information. When I've had this requirement before, I've manually captured it via a custom login page or an initUser function I've had in applications.
One of the easiest solutions is to trigger an action from a live web page that generates a database.nsf?openagent event.
like:
or
Ideally you've use the openagent to print a content type and a response, but if you don't browsers do pretty well with invalid responses from servers.
inside your "myagent" you will have the users name available to you to write it to a document.
Your next challenge will be in getting the agent to trigger, but, not too often, ideally only on login.
When a user uses a custom login form it submits the username/password and redirection url in POST method. You could change that to ...?openagent&nexturl=/blablabla.nsf
Your tiny little agent would run one and only one time upon login and update a document in a your custom logging database.
That's a developer's solution.
There are also admin solutions. The server does keep track of active web sessions, but, it does not drop them into the log.nsf like it does upon session ending for a notes session. I don't think it would be too much work from an admin standpoint to get that information there are a lot of event triggers available to you. It's just been way too long since I worked on any server that anyone cared about statistics.
I have spent several hours reading various articles on Azure Application Insights (AAI). I'm trying to determine how AAI determines what a session is and where I can find a count of unique sessions (first time visitors) vs. returning visitors. Actually, I know where to find a count of unique sessions but I don't see where I can find a count of returning visitors.
Application Insights defines session as a period of time between the first and the last telemetry item with the same session ID. Session IDs are generated by the various flavors of Application Insights instrumentation code running in the applications. For example, in web apps this is done by the JavaScript code running in a browser and automatically tracking page views.
In particular, the JavaScript code generates a new session ID when the browser loads a page for the first time. This session ID is reused for as long as any telemetry items (page views, events, etc.) are tracked by the app within 30 minutes. If no telemetry is tracked in 30 minutes, it assumes user stopped interacting with the app and the session expires. When telemetry tracking resumes after the timeout, a new session ID will be generated indicating beginning of a new user session.
To analyze the number of returning users, you can chart "Users (Unique)" and "New Users (Unique)" metrics as described here.
I'm looking to modify one of my existing portlets which is used concurrently by many users to be able to automatically poll for updates and pull down the latest data in that portlet. That way users don't have to refresh the page to see the new data. In otherwords its automatically checking for new data every 10 seconds and refreshing the data.
Almost like a chat client but its pulling down a JSON object every 10 seconds asynchronously.
No problem. On the browser side, query <portlet:resourceURL/> - this goes to the resource-serving phase of your portlet. From there you can deliver any content type you want (kind of like a servlet)
On the server side, you'll need to query for updated data from all the different users, but that's something independent of the portlet spec and rather considered business logic.