Keep it simple.  As a Product Owner, you’re responsible for the “What” and “Why”.  The team are responsible for the “How”.  You’re responsible for prioritizing the backlog, in fact this is your main responsibility.  So for those engineering stories that you simply don’t understand as they’re technical gobbledygook, then just come back to the basics of user stories: the Three Cs.

• Card
• Conversation
• Confirmation

You can write the card with the team’s guidance very easily.  Story: Ranking engine research.  As the customer options system, I need a ranking engine so that it is possible to present options in preferred order defined by a combination of business rules and customer preference.”  There, that wasn’t so hard.  There’s your Card.

Now for the Conversation.  “Guys, I need some help to prioritize this…” will lead to a conversation about size, difficulty, dependency, value from learning, buy versus build, and so on.  That’s great.  And it might not need to be written up in the story, as what value would that give.  If there’s a core agreement you want to document to remind yourselves during the sprint, sure, write that.

Now, how about the Confirmation.  That will probably mean the team needs to help write the Acceptance Criteria.  They’ll have some idea what required for the story to be complete.  Document that in the story’s acceptance criteria.

Now, you’ve done your job.  You’ve written the Card, you’ve had the Conversation so everyone’s got as much understanding as they need in their role, and you can Confirm with the team that they’ve met the Acceptance Criteria, so you can know that you actually can accept it.

Do it the way it’s designed, it turns out it’s pretty straightforward.  Don’t get caught in the weeds.